[Distutils] More questions on distutils...

[Greg Ward]

On 08 May 2000, Lyle Johnson said:
> Greg,
> 
> While working out the stuff for supporting Borland's C/C++ compiler under
> the Distutils, I've gotten a little confused about the division of
> responsbilities for the various command and compiler classes. The specific
> case I'm studying right now is the "built_ext" command (implemented in
> distutils/command/built_ext.py).
> 
> If you take a look at the build_extensions() function defined in this class,
> it appears that he "knows" some things about the "msvc" compiler. It seems
> like you'd want to avoid letting the various commands know these kinds of
> details about specific implementations of the CCompiler class. Ideally, they
> would stick to the basic CCompiler interface, no?

You are absolutely correct.  This was discussed on the list a few months 
back, but my admonishments never made it into the code.  So I've just
added this comment to build_ext.py:

            # XXX this is a kludge!  Knowledge of specific compilers or
            # platforms really doesn't belong here; in an ideal world, the
            # CCompiler interface would provide access to everything in a
            # compiler/linker system needs to build Python extensions, and
            # we would just do everything nicely and cleanly through that
            # interface.  However, this is a not an ideal world and the
            # CCompiler interface doesn't handle absolutely everything.
            # Thus, kludges like this slip in occasionally.  (This is no
            # excuse for committing more platform- and compiler-specific
            # kludges; they are to be avoided if possible!)
            if self.compiler.compiler_type == 'msvc':
                [...]

Does that answer your question?

If not, please let us know what Borland-specific kludges you need.
Perhaps the CCompiler interface could/should be expanded.  I have a
hunch that the notion of "exported symbols" belongs, but that the notion
of "file listing symbols to export" does not.  Unfortunately, this hunch
directly contradicts the present kludge in build_ext.py, as it supports
both the abstract (good) list-of-exported-symbols and concrete
(not-so-good) name-of-file-with-list-of-exported-symbols.  Yuck.  The
other reason for that kludge, "temp directory for compiler/linker
turds", could probably also be squeezed into the CCompiler abstraction.
Hmmm.
       
> I'm not attacking the current implementation -- I know that the primary goal
> to this point is to get things working. But now I'm faced with the decision
> about where to put certain Borland-specific flags and so forth -- do they
> come in solely through the new BCPPCompiler class, or do some of them also
> filter in through the build_ext command (and his siblings)?

If the flags are related to compiling code, or linking code into a
shared object (DLL), then they belong in BCPPCompiler.  If they are
specific to building Python extensions, and cannot be accomodated by the
CCompiler interface, we may have to hold our noses and put another
kludge in build_ext.py.  I'd prefer to avoid that, obviously.

        Greg
-- 
Greg Ward - Unix nerd                                   gward@python.net
http://starship.python.net/~gward/
Predestination was doomed from the start.