[Distutils] Supporting Borland's compiler

[Greg Ward]

Hi all --

this is a followup to Lyle and Thomas' exchange earlier in the week;
sorry for the delay.

1. First topic: list of symbols to export.

[Lyle]
> Since only the compiler class knows for sure how to specify the .DEF file
> name (or alternatively the exported symbols list) it seems that we should
> pass this information directly to the compiler through the
> link_shared_object() function's argument list, instead of cooking up those
> arguments in the build_ext command. I'd propose adding an additional
> argument to the function's signature (its default could be None and could be
> ignored by non-Windows compilers).

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):

'exported_symbols' would be a list of strings; it's up to the compiler
class to translate that into command-line options, a file (in the
appropriate format for that compiler) listing the names, or whatever.
For MSVCCompiler, we would add "/EXPORT:" options to the command line,
one for each string in 'exported_symbols'.  For BorlandCCompiler (or
whatever Lyle's calling it -- I suppose I should have veto power on the
name, but I still can't make up my mind), the class would have to
generate a .def file (in Borland style with underscores added/removed as
appropriate) and pass that in just the right place on the compiler
command-line.

'link_shared_object()', of course, would be adjusted similarly (since
'link_shared_lib()' is just a wrapper around 'link_shared_object()' on
both Unix and Windows.)

2. Variation on first topic: allowing sneaky symbol aliasing

[Lyle]
> The terminally clever developer who wants the (private)
> name of his module initialization function to be something else would be
> required to provide a .DEF file which exports that function as "init" +
> module, though -- there's obviously no way for distutils to guess that.

[Thomas echoes my sentiments]
> Is this possible? I think when you 'import extension' python looks
> for extension.dll or extension.pyd, then tries to locate and call
> 'void initextension (void)' and will fail if this is not found.

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!)

3. Second topic: temporary files

[Lyle]
> Changing the subject, it might also be appropriate to pass down the
> temporary files directory for the current extension's build, unless this
> kind of code:
>             
>         build_ext = self.find_peer ('build_ext')
>       build_temp = build_ext.build_temp
> 
> is considered safe. If this doesn't violate encapsulation (for the compiler
> object to know that the build_ext object has an attribute named
> "build_temp") then I'll just do this and sleep soundly ;)

If you're talking about putting this code in one (or more) of the
CCompiler classes, then Thomas was right: I don't like this.
Furthermore, it won't work -- 'find_peer()' is a method of Command, and
CCompiler is independent of that class hierarchy.

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?

        Greg
-- 
Greg Ward - Unix geek                                   gward@python.net
http://starship.python.net/~gward/
"Passionate hatred can give meaning and purpose to an empty life."
    -- Eric Hoffer