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
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
