[Distutils] Supporting Borland's compiler

[Lyle Johnson]

> 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...