Yep, I've been thinking this was needed for a while. Here's a proposed new signature for the 'link_shared_lib()' method:
def link_shared_lib (self, objects, output_libname, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, exported_symbols=None, debug=0, extra_preargs=None, extra_postargs=None):
This works for me. I'm also not attached to the "BorlandCCompiler" name, I promise!
2. Variation on first topic: allowing sneaky symbol aliasing
More importantly, is this *desirable* or *useful*? This doesn't sound like a useful thing to support; in fact, it sounds like a downright *bad* idea to let developers name their module initializer anything other than "init" + extension_name. (Assuming that it even works -- if the symbols exported from a DLL really can be aliased in the way that Lyle's "initmodule = _initmodule" example implies, then that demolishes Thomas' argument... but it doesn't make this kind of trickery a good idea!)
You can definitely alias exported symbol names; look up the MSDN documentation for the /EXPORT switch if you are still a doubter! But I meant for my use of the phrase "terminally clever" to indicate that developers who do this for Python extensions should be, um, terminated ;) So I agree with both you and Thomas that we shouldn't give them this hook.
3. Second topic: temporary files
I think the right thing to do is add a 'temp_dir' attribute to CCompiler. (I see no reason to allow overriding this in every method.) Currently this would not gain much, just the ability to move a bit of the MSVC-specific code out of build_ext.py (specifically, the stuff that generates the /IMPLIB: option). But if it's necessary to support Borland's compiler cleanly, I'm willing to do it.
Here are proposed semantics for 'temp_dir': * files that are obviously compiler/linker turds (like the stuff Lyle is talking about, and the MSVC turds that Thomas took care of several months ago by generating that /IMPLIB: option) would unconditionally go in 'temp_dir' * intermediate products, specifically object files, would go under 'temp_dir' unless you pass 'output_dir' to 'compile()' * 'temp_dir' would really be the root of a temporary tree, to avoid possible name collisions. Eg. if you compile "src/foo/a.c" and "src/bar/a.c", you'd get "<temp_dir>/src/foo/a.o" and "<temp_dir>/src/bar/a.o" * in the distutils context (ie. the "build_ext" command), temp_dir would be build/temp.<plat> -- ie. build_ext would do something like self.compiler.temp_dir = self.build_temp and that's the only use it would have for 'self.build_temp' * the compiler classes would be responsible for making sure any output directories (temp_dir or otherwise) exist before writing to them * the compiler classes are *not* responsible for cleaning up the temp dir -- that way, we can reuse .o files across builds. In the Distutils context, the user is responsible for cleaning via the "clean" command
Sound reasonable?
Yes, this sounds great! Anxiously awaiting the next CVS update...