[Distutils] Compiler abstractiom model

[Greg Ward]

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