[build_ext] more than one external library

Hi, I use the distutils shipped with Python 2.4 on a i686-pc-linux-gnu system. I am wondering how can I pass more than one external library to distutils' build_ext option (on the command line or even better via setup.cfg)? In analogy to --include-dirs I'd expect ./setup.py build_ext --libraries A:B to generate a linker call similar to: g++ -lA -lB # ... other arguments and options But I get: g++ -lA:B # ... I also tried ./setup.py build_ext --libraries 'A B' ./setup.py build_ext --libraries A B ./setup.py build_ext --libraries A,B ./setup.py build_ext --libraries A --libraries B but to no avail. (In the last case the second --libraries option seems to overwrite the first one.) Is this feature missing and I need to put the library list in the libraries option of the respective Extension constructor in setup.py? Or did I fail to try the correct syntax? Best regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

Hi, On Fri, Apr 15, 2005 at 03:09:26PM +0200, Christoph Ludwig wrote:
can anyone help with this one? In case you wonder why I need to pass the library names on the command line of setup.py: My extension uses several Boost libraries. Boost uses some kind of "library name mangling" to encode the compiler, library version and build options (single vs. multi threaded, release vs. debug build) in the library names. I cannot know which build of the Boost library the user of my extension will want / need to link against. (E.g., if he user's python interpreter was built without thread support then the extension must not be linked against libboost_*mt*.) So I need to offer the users of my extension a way to override the default choice of external libraries.
Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

Christoph Ludwig wrote:
I once had the same concern, but many others, such as build_ext being very inflexible in its way to compile extension modules. What I ended up with is a set of custom commands ('config', 'build_ext', 'test', 'install...') to allow subprojects to be built with standard autotools (autoconf, make), but being ultimately controlled by distutils. I then could take advantage of distutils packaging infrastructure ('sdist', 'bdist'). Doing this the build/install procedure is now python setup.py config <all parameters you'd normally pass to 'configure'> python setup.py build python setup.py test (optional) python setup.py install It all works quite well, though I would prefer not to use a hybride build system. (I'm still waiting for alternatives such as scons or boost.build to mature.) HTH, Stefan

Hi, On Wed, Apr 20, 2005 at 08:38:11AM -0400, Stefan Seefeld wrote:
Hm, I didn't look into creating custom commands yet. It's certainly an interesting idea provided it's not too complex. (This is my first project where I use Python so I am still somewhat green.)
In the short term I will probably settle for a README that tells the user to modify the library names in setup.py. But in the long term your approach would allow me to merge the Python extension module with the library it calls. Are you in a position (and willing, of course) to share the code for above mentioned commands?
Agreed. For the time being we will have to make do, though. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

Christoph Ludwig wrote:
Sure. Have a look at http://synopsis.fresco.org/viewsvn/synopsis-Synopsis/trunk/Synopsis/dist/com... * 'config' calls 'configure' on a number of subprojects * 'build_syn_ext' runs 'make' on extension modules (completely bypassing distutils' own 'Extension' data structure !) * 'build_syn_clib' runs 'make' on subprojects that generate standalone DSOs, not meant to be directly accessed as python extensions * 'test' runs a unit/regression test suite (qmtest based) Good luck ! Stefan

On Wed, Apr 20, 2005 at 09:37:13AM -0400, Stefan Seefeld wrote:
Thanks! I will try it as soon as I have some free time. Best regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

Hi, On Fri, Apr 15, 2005 at 03:09:26PM +0200, Christoph Ludwig wrote:
can anyone help with this one? In case you wonder why I need to pass the library names on the command line of setup.py: My extension uses several Boost libraries. Boost uses some kind of "library name mangling" to encode the compiler, library version and build options (single vs. multi threaded, release vs. debug build) in the library names. I cannot know which build of the Boost library the user of my extension will want / need to link against. (E.g., if he user's python interpreter was built without thread support then the extension must not be linked against libboost_*mt*.) So I need to offer the users of my extension a way to override the default choice of external libraries.
Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

Christoph Ludwig wrote:
I once had the same concern, but many others, such as build_ext being very inflexible in its way to compile extension modules. What I ended up with is a set of custom commands ('config', 'build_ext', 'test', 'install...') to allow subprojects to be built with standard autotools (autoconf, make), but being ultimately controlled by distutils. I then could take advantage of distutils packaging infrastructure ('sdist', 'bdist'). Doing this the build/install procedure is now python setup.py config <all parameters you'd normally pass to 'configure'> python setup.py build python setup.py test (optional) python setup.py install It all works quite well, though I would prefer not to use a hybride build system. (I'm still waiting for alternatives such as scons or boost.build to mature.) HTH, Stefan

Hi, On Wed, Apr 20, 2005 at 08:38:11AM -0400, Stefan Seefeld wrote:
Hm, I didn't look into creating custom commands yet. It's certainly an interesting idea provided it's not too complex. (This is my first project where I use Python so I am still somewhat green.)
In the short term I will probably settle for a README that tells the user to modify the library names in setup.py. But in the long term your approach would allow me to merge the Python extension module with the library it calls. Are you in a position (and willing, of course) to share the code for above mentioned commands?
Agreed. For the time being we will have to make do, though. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

Christoph Ludwig wrote:
Sure. Have a look at http://synopsis.fresco.org/viewsvn/synopsis-Synopsis/trunk/Synopsis/dist/com... * 'config' calls 'configure' on a number of subprojects * 'build_syn_ext' runs 'make' on extension modules (completely bypassing distutils' own 'Extension' data structure !) * 'build_syn_clib' runs 'make' on subprojects that generate standalone DSOs, not meant to be directly accessed as python extensions * 'test' runs a unit/regression test suite (qmtest based) Good luck ! Stefan

On Wed, Apr 20, 2005 at 09:37:13AM -0400, Stefan Seefeld wrote:
Thanks! I will try it as soon as I have some free time. Best regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
participants (2)
-
Christoph Ludwig
-
Stefan Seefeld