Quoth Andrew Dalke, on 29 March 1999:
C++ template instantiation For at least some compilers, the compilation flags must be passed to the linker, because the linker instantiates templated code during a "pre-link" step so needs to know the right compilation options.
Ouch! I *knew* there was a reason I disliked C++, I just couldn't put my finger on it... ;-) Maybe we should cop out and only handle C compilation *for now*? Just how many C++ Python extensions are out there now, anyways?
compiler flags Where do I stick "-g" or "-O" in the "compile" function? (Or "-ansi", or for our SGIs, "-o32" ?) Or will you extract these from the Python compilation info? In which case, getting the values for a CPPCompiler would be tricky.
Generally, those things must be done when Python is compiled. Err, let me reiterate that with emphasis: ** COMPILER FLAGS ARE THE RESPONSIBILITY OF THE PYTHON BUILDER ** and Distutils will slurp them out of Python's Makefile (using Fred's distutils.sysconfig module) and use those to build extensions. Andrew, you use SGIs, so you can probably guess what kind of chaos would result if your sysadmin built Python with -o32 and you started building extension modules with -n32. And that's only the most obvious example of what can go wrong when you use compiler flags on a dynamically loaded object inconsistent with the binary that will be loading it. For that and other reasons, I'm quite leery of letting individual extension modules supply things like -ansi or -o32 -- those options should all be stolen straight from Python's Makefile. However, there probably should be a way to set debugging/optimization flags -- again, the default should definitely be to take them from Python's build, but I don't think inconsistent -g/-O will cause problems. (Anyone have evidence to the contrary?) However, this should not be in the CCompiler interface -- I was thinking it belongs in UnixCCompiler instead, because Unix C compilers are fairly consistent about allowing -g, -O, etc. Anything at the CCompiler level should be applicable to all compilers: compiler.debug = 1 # implies "cc -g" on Unix, something else on # other platforms compiler.optimize = 'none' # or 'medium' or 'high'
As clarification, the "add_include_dir" is for the list of directories used for *all* compilations while the compile(... include_dirs=dirs) is the list needed for just the given source file?
Yes; any directories supplied to 'add_include_dir()' and 'set_include_dirs()' would affect *all* compilations. Directories supplied to 'compile()' through the 'include_dirs' named parameter would be *added* to the standard list for that compilation step only. Ditto for macros, libraries, library directories, etc.
I take it the compile() include dirs will be listed first, or is it used instead?
Good point. "added" should be "prepended" above, for maximum clarity.
Is there any way to get the list of include files (eg, the initial/default list)?
Oh, probably. I just haven't documented it. ;-) I think David Ascher's idea of exposing the actual list might be nicer overall -- I'll reply to his post separately.
As I recall, not all unix-y machines have .so for their shared library extensions. Eg, looking at the Python "makesetup" script, it seems some machines use ".sl". I don't think Python exports this information.
I was just using '.so' as an illustration. I'll have to spend some time grovelling through Python's Makefiles and configure stuff to verify your last statement... I certainly hope that information is available, though!
I believe at times the order of the -l and -L terms can be important, but I'm not sure. Eg, I think the following
-L/home/usa/lib -lfootball -L/home/everyone_else/lib -lfootball
lets me do both (American) football -- as in Superbowl -- and soccer (football) -- as in World Cup. Whereas
-L/home/usa/lib -L/home/everyone_else/lib -lfootball -lfootball
means I link with the same library twice.
Auuugghhh!!! This seems like a "feature" to avoid like the plague, and probably one that's not consistent across platforms. Can anyone back up Andrew's claim? I've certainly never seen this behaviour before, but then I haven't exactly gone looking for such perversion. 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