[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-distutils-sig
Subject:    [Distutils] Re: order on link
From:       gward () cnri ! reston ! va ! us (Greg Ward)
Date:       1999-10-01 12:33:58
Message-ID: 19991001083357.A14356 () cnri ! reston ! va ! us
[Download RAW message or body]

On 30 September 1999, Paul F. Dubois said:
> > Hmmm, so I am.  That's a bug.  The fix is trivial: see lines 225-226 of
> > distutils/unixccompiler.py -- just change the order of 'objects' and
> > 'lib_opts'.
> 
> That did the trick!

OK, I'll keep the fix for 0.11.

> No idea. This sensitivity varies among Unix compilers, too. That leads to
> the nonsense of having to list a library twice.

Luckily, that's no problem with Distutils -- you just put it in the
'libraries' list twice, and it winds up on the command line twice.  This
will only handle mutual dependencies amongst libraries -- .o files are
always elsewhere on the command line (because of line 225-226 in
distutils/unixcompiler.py), so the system can't handle every
possibility.

> The .o's get left in the directory with setup.py; should be squirreled away
> someplace else. To allow for building for mutiple platforms it would be nice
> if the build products went into a platform-specific directory, eg.
> build/linux2. That way when you make a bug fix on one platform you don't
> have to blow everything away to do the next one.

Yeah, I know about that.  The status quo is no worse than a
Makefile.pre.in system -- Numeric's current build system just drops .o
files in the current directory -- so I figured it was OK if I did that
in this version.  There actually need to be *two* "build" directories:
one for transient files (.o), and one for permanent files to install.
And you're right, both of them need to be partitioned by platform,
eg. "build.platlib-i86-linux" or "build.platlib-sparc-sun-solaris".

My inclination would be to leave the source directories untouched, and
put all intermediate and final files in other directories that are
completely under Distutils control.  Anyone see problems with that
approach?

Also, does anybody have Python code that divines that GNU style
"cpu-vendor-os" string, or something similar?  sys.platform is a start,
but not enough because it doesn't say anything about the CPU
architecture.

        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


[prev in list] [next in list] [prev in thread] [next in thread]