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
Quoth Paul F. Dubois, on 30 March 1999:
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.
The way I see Distutils being extended is by people writing new command classes. Let's say LLNL wants to distribute a Python module with a (shudder) FORTRAN back-end, and Distutils doesn't support FORTRAN. (Sorry, not a lot of call for it.) The general idea, which I have not fully thought through, is that you would write a "BuildFortran" class, and include it with your code -- right there in setup.py if it's not too big. Then, your setup.py would look something like this: class BuildFortran: # ... setup (name = "llnl-fortran-module", version = "1.0", description = "Front end to some crufty FORTRAN code", cmdclass = {build_fortran: BuildFortran}, py_modules = ['mod1', 'mod2'], fortran_extensions = ['fext1', 'fext2']) The part that I haven't really thought through is how the Distribution class is supposed to know that 'fortran_extensions' is a valid option. Perhaps I'll continue to punt on checking options for validity, although it is nice to catch typos! Also, in the current model you'd have to subclass the 'Build' class (which implements -- surprise! -- the 'build' command) so that it calls build_py, build_ext, and build_fortran. Perhaps there should be a mechanism to adjust the "wrapper" commands (currently 'build' and 'install') so they can call more than just the commands hard-coded into them. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
Greg Ward wrote:
... The way I see Distutils being extended is by people writing new command classes. Let's say LLNL wants to distribute a Python module with a (shudder) FORTRAN back-end, and Distutils doesn't support FORTRAN. (Sorry, not a lot of call for it.) The general idea, which I have not fully thought through, is that you would write a "BuildFortran" class, and include it with your code -- right there in setup.py if it's not too
You can also save yourself a lot of time by building something that seems reasonable and waiting for the feedback from people who need it and/or feel it is important. No sense in getting yourself all bound up and unmoving, just because you're trying to solve a 5% case. Build something for the 95% case and delegate the 5% to the people who care about it. Cheers, -Greg "Minimalist" Stein -- Greg Stein, http://www.lyra.org/
Quoth Greg Stein, on 31 March 1999:
You can also save yourself a lot of time by building something that seems reasonable and waiting for the feedback from people who need it and/or feel it is important.
Umm, that *is* how I'm attacking the problem! I just want to make sure that the design is open enough that people can attack that last 5% (or 10% or 20% or whatever) without running up against the brick wall of a short-sighted design. That's the biggest pitfall of OO: sure it leads to extensible and reusable designs, but only if you carefully build extensibility and reusability into those designs. That's what I'm trying to do with Distutils, and the point of this whole discussion is to get the feedback I need to see if the design is indeed extensible and reusable enough! I think we're in agreement here, except that I'm not even shooting for a 95% job. IMHO getting 90% or 80% of the way there would be enough to build on. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
participants (3)
-
Greg Stein -
Greg Ward -
Paul F. Dubois