Re: Distutils-SIG digest, Vol 1 #79 - 1 msg

Greg, Only a few comments: 1) There's no command line interface on the Mac, but the compiler they use (Metroworks) can be controlled through an external "event" interface (Apple's response to COM, except Apple had it long before COM even existed :-). So there's no reason why it couldn't be done on the Mac. 2) I'm not sure if you're trying to add a method for each of the typical cc options (I recognized -I, -D, -U, etc.). Looks like you're missing -R, which is like -L but works at runtime, and is needed if you're using shared libraries that live in non-standard places. 3) I stringly prefer shared lib over dynamic lib (on Windows everyone calls them "DLL" anyway). 4) Do you really not want to support cross-compiling? The Windows/ce folks will regret that ;-) But I don't think you need to support -I (without a directory) for that; typically the compiler has a different name and all is well. I bet -I without args is intended for people who want to experiment with a hacked set of system includes; they can add it to the compiler command name if they want to. 5) When creating a shared lib from libraries only, you need to specify an entry point. Is this useful to support? 6) I haven't been following distutils very closely, so forgive me if the above makes no sense :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

On 10 July 1999, Guido van Rossum said:
Oops, forgot about that one because I always forget about it myself when writing Makefiles, building binaries, etc. How do 'add_runtime_library_dir()' and 'set_runtime_library_dirs()' sound, apart from being rather windy?
3) I stringly prefer shared lib over dynamic lib (on Windows everyone calls them "DLL" anyway).
Yeah, I prefer that too. Done, "shared lib" it is.
4) Do you really not want to support cross-compiling? The Windows/ce folks will regret that ;-)
Nothing against cross-compiling in principle; I just don't need any more distractions. I'd love to see someone who knows about it hack it in, but right now it's kind of academic since there's no mechanism to select which concrete CCompiler subclass is used.
Actually, that won't work, since I intend the command name to be *just* the command name, and options to be supplied as a list of strings. (The best way to avoid shell quoting hell is to avoid the shell!) If someone wants "-I" on the command line, they'll have to use the as-yet-fictitious "Add these compiler options dammit!" interface. A more serious problem occurred to me sometime in the last week: there are not two, but *three* levels of include directories (and library directories, and libraries, and link objects) included in the compile/link steps: those mandated by the system (/usr/include, libc.so), those coming from Python's Makefile (/usr/local/include/python1.5), and those supplied by the various CCompiler set/add methods. Currently the first two are both carved in stone; the user of CCompiler can only add to or replace his own list of include/library directories, libraries, etc. I think this is another one of those things that won't matter for most Python extensions, but will be a pain for those people who really need it. Hmm...
5) When creating a shared lib from libraries only, you need to specify an entry point. Is this useful to support?
Well, you learn something every day... I didn't even know this was possible! Can you point me at some Fine Manual that explains this? 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

On 10 July 1999, Guido van Rossum said:
Oops, forgot about that one because I always forget about it myself when writing Makefiles, building binaries, etc. How do 'add_runtime_library_dir()' and 'set_runtime_library_dirs()' sound, apart from being rather windy?
3) I stringly prefer shared lib over dynamic lib (on Windows everyone calls them "DLL" anyway).
Yeah, I prefer that too. Done, "shared lib" it is.
4) Do you really not want to support cross-compiling? The Windows/ce folks will regret that ;-)
Nothing against cross-compiling in principle; I just don't need any more distractions. I'd love to see someone who knows about it hack it in, but right now it's kind of academic since there's no mechanism to select which concrete CCompiler subclass is used.
Actually, that won't work, since I intend the command name to be *just* the command name, and options to be supplied as a list of strings. (The best way to avoid shell quoting hell is to avoid the shell!) If someone wants "-I" on the command line, they'll have to use the as-yet-fictitious "Add these compiler options dammit!" interface. A more serious problem occurred to me sometime in the last week: there are not two, but *three* levels of include directories (and library directories, and libraries, and link objects) included in the compile/link steps: those mandated by the system (/usr/include, libc.so), those coming from Python's Makefile (/usr/local/include/python1.5), and those supplied by the various CCompiler set/add methods. Currently the first two are both carved in stone; the user of CCompiler can only add to or replace his own list of include/library directories, libraries, etc. I think this is another one of those things that won't matter for most Python extensions, but will be a pain for those people who really need it. Hmm...
5) When creating a shared lib from libraries only, you need to specify an entry point. Is this useful to support?
Well, you learn something every day... I didn't even know this was possible! Can you point me at some Fine Manual that explains this? 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 (2)
-
Guido van Rossum
-
gward@cnri.reston.va.us