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.