[Distutils] Compiler abstractiom model

[Paul F. Dubois]

Just to chime in about the unmentionable, I have a tool for connecting
Fortran and Python (as do others; mine isn't ready for the light of day yet)
and unfortunately the existing Setup scheme makes me compile my Fortran
separately in a library. I don't have any way to piggyback on what Python
has learned about the platform. This is too bad. I am sure it isn't the
Python community's job to solve the Fortran 90 make problem but there are
days when I dream about it.

The "right" object-oriented approach should allow some way to extend the
system, e.g. adding suffices or file names together with info about how to
compile them.

-----Original Message-----
From: Mark Hammond <MHammond@skippinet.com.au>
To: distutils-sig@python.org <distutils-sig@python.org>
Date: Tuesday, March 30, 1999 3:50 PM
Subject: RE: [Distutils] Compiler abstractiom model


>> > 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.
>
>
>_______________________________________________
>Distutils-SIG maillist  -  Distutils-SIG@python.org
>http://www.python.org/mailman/listinfo/distutils-sig
>
>