[Distutils] DEF Files

[Anthony Pfrunder]

On Tue, 14 Sep 1999, M.-A. Lemburg wrote:

> Anthony Pfrunder wrote:
> > 
> > On Tue, 14 Sep 1999, Robert Kern wrote:
> > 
> > > FWIW, I agree with David that requiring modifying the source of an
> > > extension is not a good thing.  It only adds a headache for people trying to port from *NIX to
> > > Windows (and we have enough to deal with,
> > > believe me), and it pollutes the code with weird MS extensions.
> > ... and weird unix only utilites such as sed [sorry, my Windows side speaking]
> 
> I don't really get your points here... you can stick all those
> weird symbols into macros and then forget about them.

I was refering to the current process for building python.  At the
moment, non-unix platforms use a totally different build system to that
of unix.  This means that when new modules are added several build systems
need to be updated instead of one.  distutil should provide a mechanism so
that only one build system should be updated.  Also, this build system
should use python as much as possible and not rely on platform specific
extensions such as SED or /export:<symbol> except in platform specific
meta-files.

The approach I use for handling source mods is to create a generic macro
which is then included from the appropiate compiler meta-file.  The
disadvantage of lumping all the #defines in one place is that it makes it
"look" more complex as it has elements not relevate to the users
compilation platform.  These source mods (compiler-metafiles) are then
applied using a context
diff, compiled and then removed.  This means that the user is looking at
the generic version of the source with no platform specific stuff to add
complexity.  If they want a platform specific version they say "make
source-version-$(PLATFORM)" to get this (for debugging etc).

Cheers,

Anthony Pfrunder
Computer Systems Engineering
University of Queensland