Greg Ward wrote:
[my suggestion]
initfunc_name = "init" + string.split(ext.name,'.')[-1] if initfunc_name not in ext.export_symbols:ext.export_symbols.append(initfunc_name)[Rene agrees]
OK, I think you are right, if one wants to build none Python dll's he will not use build_ext to do this.
OK, can you make this change and include it in your next patch?
I used 'extend' to be able to write " ld_args.extend([',','some_other_param']) ", but I never needed it in some places and simply forgot to replace it with 'append' in the final patch.
[...]
It is not necessary to have these commas as separate words, but they don't really belong to a output filename or a library name, this is the other reason why I made them in separate words.
OK. I'd really like to see that code cleaned up: can you take care of that too? If it doesn't matter how things are broken up into words, how about just economizing on the amount of Python code? The current implementation seems rather bloated to me.
It is not as easy as you may think, I just spotted a potential problem before it could arise. If I would write ...append(",,%s," % filename) and filename would contain a blank ("/a b/file") then spawn would quote it as whole ",,/a b/file,". And this is probably wrong. So we should insert file names as single words in the list. (Don't say blanks in file names are not allowed in python module names, THIS is a generic compiler class which could also be used for other purposes.)
I've added the 'debug' flag to the official 'find_library_file()' signature specified by CCompiler. I've also rewritten the implementation in both MSVCCompiler and BCPPCompiler. Here's the MSVC one (it's a bit simpler -- no prefix): ... and here's the BCPP version: ... Do those look right to you? Obviously this is completely untested, but I think both are a huge improvement so I'll check 'em in anyways. Make sure you "cvs up" if you have any patches for msvccompiler.py or bcppcompiler.py!
Also in the "obvious" category: these should be combined, presumably when someone (probably me, sigh) sits down and factors WindowsCCompiler out of MSVCCompiler and BCPPCompiler.
(We can't change the config.h file in existing installations this is why I put the comment in there. So if a user got problems he finds a hint where this could come from.)
Sorry, which comment? Do you mean the warning that's printed if 'check_config_h()' doesn't like what it finds?
I meant this one:
# either exchange python15.lib in the python libs directory against # a Borland-like one, or create one with name bcpp_python15.lib # there and remove the pragmas from config.h #libraries.append ('mypylib') libraries.append ('import32') libraries.append ('cw32mt')
- you shouldn't write to stdout or stderr in a compiler class -- use the 'announce()' method. I should really add a 'debug_print()' method; that would be handy.
If you add 'debug_print()' I will use it.
Added it. Please change your prints or writes or whatever they are.
Already done.