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