[Distutils] Re: distutils and C++ extensions

Stefan Seefeld seefeld@sympatico.ca
Fri Aug 23 09:36:02 2002


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