[Distutils] Re: CygwinCCompiler, msvc hack, BCPPCompiler

[Greg Ward]

On 29 June 2000, Rene Liebscher said:
> ---- CygwinCCompiler ------------
> 
> OK, it should now be better to read. I also included your other changes
> (set_executables, build_temp.)

Looking better.  Still some problems, which I will address below.

> ----- msvc hack -----------
> 
> I also had a look at this msvc hack in build_ext. I think it is now
> possible
> to get rid of it. It does several things which could be done in an other 
> way or shouldn't be done at all.
> 
> First, it tries to find a def-file in the source directory if 
> none is given. I think one should specify this explicitely, who
> knows if it is really the right file and moreover it overwrites
> any export_symbols given to Extension().

I have never been fond of this bit of code.  I have always considered it
unnecessary, given that 1) there is always exactly one symbol to be
exported from a Python extension, and it is trivially derived from the
extension name, and 2) we can generate an "/export:" option for that
exported file.  Somehow Thomas Heller (I think I can blame him ;-)
talked me into leaving it in.

But Thomas is on vacation now.  (Hee hee hee.)  I think I'll take a page 
from Guido's book and remove what I consider to be a broken feature.  If 
nobody howls, it stays out.

*poof!* it's gone.

> Then it uses the module_name to create an export directive 
> for the procedure 'init{modulename}'. It is possible to extract
> this name from the output filename (see (bcpp|cygwin)compiler.py )
> I think this export parameter should be only used if neither a def
> file nor a list of symbols is given. (Then you could use your compiler
> classes also for non python dll's by specifying [] as export_symbols
> list.) 

No: that would involve putting knowledge about Python extensions into a
CCompiler class, which I strive to avoid.  (Went to a lot of trouble
this weekend to get knowledge of the sysconfig module out of
UnixCCompiler, and I don't want to have to go through that again!)

It is acceptable, but definitely to be avoided, to add platform- and
compiler-specific hacks to build_ext.py.  But I want to keep
Python-extension-building hacks out of the CCompiler classes, because
they can and should be useful for more than just building Python
extensions.

This, of course, is the remaining problem (that I see) with
cygwinccompiler.py: it figures out symbols-to-export by looking at the
output filename, which is flagrantly wrong (ie. totally specific to
building Python extensions).  *Please* fix this!

> When I looked at the code of build_ext I found you are not using 
> export_symbols as parameter to link_shared_object. Also you are not 
> using any of this export_* values from the Extension class.
> This should be changed. But there is one point which is not clear.
> There is no parameter at link_shared_object for export_symbols_file.
> Either we add this or we change the semantics of the existing
> export_symbols a bit.

Yeah, those features were added so we could reduce (if not completely
eliminate) the MSVC-specific hackery in build_ext.py.  Looks like I
never finished the job; kinda hard for me to do since I can't test it.
I'd love to see a patch that does this, thought!

> And finally it uses the build_temp path for it implib directive.
> We have now this new extra parameter to link_shared_library, so
> this is also not a problem.   

Hey, good point.  Can you submit a patch for that too?

        Greg
-- 
Greg Ward - programmer-at-big                           gward@python.net
http://starship.python.net/~gward/
It has just been discovered that research causes cancer in rats.