[Distutils] Compiler abstractiom model

[Mark Hammond]

> > Quoth David Ascher, on 29 March 1999:
> > > On windows, it is sometimes needed to specify other files
> which aren't .c
> > > files, but .def files (possibly all can be done with
> command line options,
> > > but might as well build this in).  I don't know how these
> should fit in...
> >
> > Are they just listed in the command line like .c files?  Or
are they
> > specified by a command-line option?  Would you use these in
> code that's
> > meant to be portable to other platforms?
>
> Yes, no, and yes. =)
>
> E.g. Python extensions need to declare the 'exported' entry
> point.  This
> can be done either by modifying the source code (bad for
> portable code,
> requires #ifdef's etc.), by specifying a command-line option,
or by
> including a .DEF file.

Just to follow up on this, many obscure options may need to be
passed to the Windows linker, but they do require their own
option - they are not passed as normal files.  Examples are
/DEF: - the .def file David mentions, /NOD:lib - to prevent a
default library from being linked, /implib:lib to name the built
.lib file, etc.

It wasnt clear from David's post that these need their own
option, and are not passed as a simple filename param to the
linker....

Building from what Greg said, I agree that _certain_ command-line
params can be mandated - they are designed not to be
configurable, as messing them will likely break the build.  But
there also needs to be a secondary class that are virtually
unconstrained.

[Sorry - as usual, speaking having kept only a quick eye on the
posts, and not having seen the latest code drop...]

Mark.