On Tue, 30 Mar 1999, Greg Ward wrote:
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.
But, as I said emphatically in my last post, those sorts of things must be supplied when Python itself is built. I'm already allowing control over include directories and macros -- which are essential -- so I'm willing to throw in -g/-O stuff too. But if we allow access to arbitrary compiler flags, you can kiss portability goodbye!
Not really -- you simply need to make the consequences of messing with certain objects clear to the user, so that if s/he wants portable, s/he does X, Y and Z, but if s/he wants to distribute the code to a specific machine but with all the other machineries that distutils provides, then s/he can do so. IMHO, portable packaging will come by folks first using it to package their non-portable code because it's easier than doing it the old way. --david