Christoph Ludwig wrote:
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*.)
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