Re: distutils and C++ extensions
On 23 August 2002, Stefan Seefeld said:
I'v mailed to various related newsgroups/mailing lists but nobody answered, so please excuse for the intrusion.
Did you try distutils-sig@python.org? That's where I send people with distutils questions, but if you already tried there...
I'v some trouble setting up a setup.py script for an extension module which I want to port from a autotools based build system to distutils. The module consists of various subdirectories, each with a set of files. The problem is:
* some of the names clash (i.e. syn/hash.cc and ucpp/hash.c), i.e. the way distutils works compiles different source files to the same object file. I can't find a way to instruct distutils to change the output file name (or directory) per file
That shouldn't happen. As I recall, distutils should compile C/C++ source as follows: syn/hash.cc -> build/temp.$plat/syn/hash.o ucpp/hash.c -> build/temp.$plat/ucpp/hash.o (where $plat is eg. "linux-i686-2.1", ie. the OS, hardware, and Python version). If that's not happening, it's a bug.
* the different subdirectories used to have different Makefiles, thus allowing different macro definitions, etc.
* different subdirectories use different compilers (gcc vs. g++) and different compiler options
Ouch.
Is there any way to address these issues with distutils without a major hack ?
I don't think so. I never figured out a good way to handle that stuff, but I haven't been near the distutils since October 2000. AFAIK no one has figured out a good way to handle that stuff. Sorry. You might try multiple setup scripts, and then a meta-setup script to tie them all together. I think Andrew Kuchling experimented with that sort of setup when he distutil-ized ZODB; as I recall, it sort-of worked, but wasn't exactly a stunning success. Greg -- Greg Ward - just another Python hacker gward@python.net http://starship.python.net/~gward/ Gee, I feel kind of LIGHT in the head now, knowing I can't make my satellite dish PAYMENTS!
Greg Ward wrote:
* some of the names clash (i.e. syn/hash.cc and ucpp/hash.c), i.e. the way distutils works compiles different source files to the same object file. I can't find a way to instruct distutils to change the output file name (or directory) per file
That shouldn't happen. As I recall, distutils should compile C/C++ source as follows:
syn/hash.cc -> build/temp.$plat/syn/hash.o ucpp/hash.c -> build/temp.$plat/ucpp/hash.o
(where $plat is eg. "linux-i686-2.1", ie. the OS, hardware, and Python version).
If that's not happening, it's a bug.
ok, it's a bug. Should I file it somewhere ? I may even try to fix it...
* the different subdirectories used to have different Makefiles, thus allowing different macro definitions, etc.
* different subdirectories use different compilers (gcc vs. g++) and different compiler options
Ouch.
Is there any way to address these issues with distutils without a major hack ?
I don't think so. I never figured out a good way to handle that stuff, but I haven't been near the distutils since October 2000. AFAIK no one has figured out a good way to handle that stuff. Sorry.
well, it doesn't look very difficult to me. All that is necessary is some extension substructure. Instead of describing an extension module by a single 'Extension' tuple of options (i.e. source files + options how to compile time), an extension should contain a list of 'extension components'. Each component then contains what 'Extension' now contains, and the module is linked by linking all the objects from all these components together. It's just one more indirection, doesn't look too hard to implement. What do you think ?
You might try multiple setup scripts, and then a meta-setup script to tie them all together. I think Andrew Kuchling experimented with that sort of setup when he distutil-ized ZODB; as I recall, it sort-of worked, but wasn't exactly a stunning success.
see above, I think my proposition is similar, but addresses the problem at a better place. Let me know what you think, and whether there is a way to make that work (with backward compatibility and all...) Best regards, Stefan
participants (2)
-
Greg Ward
-
Stefan Seefeld