[SciPy-dev] Getting rid of parasite libraries when linking

Pearu Peterson pearu at cens.ioc.ee
Thu Feb 14 06:16:45 CST 2002


On Thu, 14 Feb 2002, eric wrote:

> > However, note that C libraries are still linked against all extension
> > modules. For example,
> >   -lc_misc -lcephes -lgist
> > (and only these) appear in all linking execution arguments. Actually this
> > is a problem only when using the top level setup.py and we should also
> > consider fixing this for C libraries. It makes little sense to use global
> > libraries list anyway, I think. Or can you think any possible application
> > for using global libraries and library_dirs keywords in the toplevel
> > setup.py?. Or should we invent c_libraries? Or do you have any better idea
> > how to get rid of these parasite libraries?
> 
> Seems like a c_libraries idea would parallel our needs a little more, but it
> isn't "standard".  Not that that has stopped from re-inventing half of
> distutils, but it does make you pause.  I'm a 0 on this one. (+1 being for it, 0
> neutral, -1 against as on the python-dev) list.

When scanning python docs about this, I found no hints about how to
proceed from our situation. This is also expected because the toplevel
scipy setup.py is like "a non-standard super" setup.py. Namely, the
standard distutils does not support packages of extension packages
(certainly it supports packages of pure packages). So, scipy_distutils is
not quite re-inventing distutils but more like extending it for packaging
of extension packages.

Inventing c_libraries certainly does not break the "standard" but I have
no glue how the standard distutils will evolve on supporting extension
packages (if at all). And it is certainly better to use standardized
hooks. On the other hand, scipy_distutils has passed by distutils on this
issue and may be distutils should copy our experience from 
scipy_distutils. Though, I find this rather unlikely based on my past
experience when pinging distutils about supporting Fortran stuff.

One option would be also to soft-break the "standard" by using existing
'libraries' keyword in the similar way as 'fortran_libraries'. This hack
would be easiest to implement. In fact, the current scipy building process
uses already the 'libraries' keyword as it would be 'c_libraries'
keyword, just it has this nasty effect of spreading libraries to all
linking calls.

Pearu




More information about the Scipy-dev mailing list