How to test python extension modules during 'make check' / 'make distcheck'?

Discussion in 'Python' started by Mark Asbach, Nov 2, 2006.

  1. Mark Asbach

    Mark Asbach Guest

    Hi pythonians,

    I'm one of the maintainers of an open source image processing toolkit
    (OpenCV) and responsible for parts of the autotools setup. The package
    mainly consists of four shared libraries but is accompanied by a python
    package containing some pure python code and of course extension modules
    for the four libraries.

    Now during the last month we were preparing a major release which means
    testing, fixing, testing, fixing, ... in the first degree. Typical
    functionality of the shared libraries is verified during 'make check'
    and 'make distcheck' by binaries that are linked against the libraries
    (straight forward) and are listed in the 'TESTS' automake primary.

    Unfortunately, many problems with the python wrappers arose from time to
    time. Currently we have to build and install before we can run any
    python-based test routines. When trying to integrate python module
    testing into the automake setup, there are some problems that I couldn't
    find a solution for:

    a) the extension modules are built in different (other) subdirectories -
    so they are not in the local path where python could find them

    b) the libraries and extension modules are built with libtool and may
    have rpaths compiled in (is this problematic)?

    c) a different version of our wrappers might be installed on the testing
    machine, somewhere in python/site-packages. How can I make sure that
    python only finds my 'new' local generated modules?

    Since the project is targeted at C/C++ developers in the first degree
    and the python wrappers are just an add-on, there is no chance to
    migrate it away from automake to someting else (like distutils, etc.).

    Did someone solve a similar problem?

    Thanks in advance,

    Mark

    P.S.: I'll post a similar message to the automake mailing list, but
    probably python developers are a minority there ...

    --
    Dipl.-Ing. Mark Asbach Tel +49 (0)241-80-27677
    Institute of Communications Engineering Fax +49 (0)241 80-22196
    RWTH Aachen University, Germany http://www.ient.rwth-aachen.de
    Mark Asbach, Nov 2, 2006
    #1
    1. Advertising

  2. Mark Asbach

    Leo Kislov Guest

    Mark Asbach wrote:
    > Hi pythonians,
    >
    > I'm one of the maintainers of an open source image processing toolkit
    > (OpenCV) and responsible for parts of the autotools setup. The package
    > mainly consists of four shared libraries but is accompanied by a python
    > package containing some pure python code and of course extension modules
    > for the four libraries.
    >
    > Now during the last month we were preparing a major release which means
    > testing, fixing, testing, fixing, ... in the first degree. Typical
    > functionality of the shared libraries is verified during 'make check'
    > and 'make distcheck' by binaries that are linked against the libraries
    > (straight forward) and are listed in the 'TESTS' automake primary.
    >
    > Unfortunately, many problems with the python wrappers arose from time to
    > time. Currently we have to build and install before we can run any
    > python-based test routines. When trying to integrate python module
    > testing into the automake setup, there are some problems that I couldn't
    > find a solution for:
    >
    > a) the extension modules are built in different (other) subdirectories -
    > so they are not in the local path where python could find them


    As I understand it's not python that cannot find them but dynamic
    linker. On ELF UNIX systems you can set LD_LIBRARY_PATH to help linker
    find dependencies, on Windows -- PATH. If you need details, you can
    find them in dynamic linker manuals.

    > b) the libraries and extension modules are built with libtool and may
    > have rpaths compiled in (is this problematic)?


    libtools seems to have some knobs to cope with rpath:
    http://sourceware.org/ml/bug-glibc/2000-01/msg00058.html

    > c) a different version of our wrappers might be installed on the testing
    > machine, somewhere in python/site-packages. How can I make sure that
    > python only finds my 'new' local generated modules?


    Set PYTHONPATH to the directory where locally generated modules are
    located. They will be found before site packages.

    -- Leo
    Leo Kislov, Nov 3, 2006
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anand
    Replies:
    3
    Views:
    866
    Tim Daneliuk
    Nov 8, 2003
  2. Torsten Mohr
    Replies:
    4
    Views:
    367
    Steve Menard
    Jun 2, 2004
  3. traveller
    Replies:
    0
    Views:
    1,170
    traveller
    Jan 8, 2008
  4. Skybuck Flying

    Call oddities: &Test() vs &Test vs Test

    Skybuck Flying, Oct 4, 2009, in forum: C Programming
    Replies:
    1
    Views:
    678
    Skybuck Flying
    Oct 4, 2009
  5. Dmitry Korolyov

    Datagrid not updated during delete, but updated during insert and update

    Dmitry Korolyov, Sep 22, 2003, in forum: ASP .Net Datagrid Control
    Replies:
    0
    Views:
    397
    Dmitry Korolyov
    Sep 22, 2003
Loading...

Share This Page