[Gdal-dev] status of ldshared build? (or, other options for OSX framework build)

[Christopher Barker]

First,

Thanks for all this OS-X work William!


> it looks like libtool is simply getting 
> in the way - it can't make a library file with a 'lib' prefix and 
> '.dylib' extension. 

It sounds likethe OS-X port of libtool is broken and/or incomplete -- 
are the libtool developers open to fixing this kind of stuff?

I don't have my OS-X box in front of me, but is the lib* convention not 
usually used with *.dylib? (ie,. it's either the old *nix lib*.so or 
just *.dylib)

Anyway, I'm pretty sure I've seen python extensions built against 
*.dylibs before -- why do we need the lib*.dylib convention?


> And without knowing the exact path to the built 
> python or installed python gdal libs (they're controlled by 
> distutils/setuptools), there is no way to to postprocess them into 
> framework binaries.

Now I'm confused -- isn't the goal here to build a GDAL Framework that 
the python extensions can use? In which case it seems you'd need to hack 
  the GDAL framework, not the python install.

Anyway, if you sue the python that you're running setup.py with, you 
should be able to use it to figure out the path to the python 
installation (or could you hack it before installing, in which case, 
it's in the build dir that distutils creates)

I wonder if some of the complication is coming from the order that we're 
using to do things -- if we did:

build GDAL
install GDAL lib (framework on OS-X)
build python extensions (using installed GDAL)
install python extensions

would that work better? I guess I've see this kind of thing done two ways:

Either the lib is there just to support the python extensions (like 
PIL), in which case it is built, then the extensions built, then the 
whole shebang installed in site-packages

Or the lib exists outside of python, and you want to use in in 
non-python tools (that would be GDAL) -- in that case, it's usually 
built and installed separately.

Then there's a third case -- like wxPython -- wx is used by other, 
non-python apps, but wxPython needs a specific build, so it's usually 
built and installed alongside the extension, not in a central location. 
However, the lib is still built and installed before building the python 
lib.

> One possibility is for configure to somehow get from python the exact 
> install path and store it in gdalmake.opt.

I'd think there'd be some way to query distutils for this. This looks 
like it:

 >>> distutils.sysconfig.get_python_lib()
'/usr/lib/python2.5/site-packages'

> My other thought is to use the ldshared build, where we have complete 
> control over the compile and link commands configurations and build the 
> binary correct from the start.  then the python libs link correctly and 
> no post-processing is needed.  Currently, it looks like the ldshared 
> build is taylored to linux only.  I recall hearing some time ago that it 
> wasn't really being maintained?

I presume that libtool has been adopted for a good reason, but I'll let 
someone who knows comment on that. It does seem like a bad ides to try 
to maintain multiple systems.

Howard Butler wrote:
> People seem to prefer the 'make install' approach of manually copying 
> things as we did in the past,

What's the difference? the scripts are useless without the python 
bindings, so It makes more sense to me to have distutils install them 
(or is it hard to get them in the right place that way?)

Given what's going on with the issues on OS-X, I'm feeling more and more 
like I'd rather the python extensions, and accompanying scripts, were 
separately built and installed with distutils/setuptools, and stop 
trying to integrate it into one make && make install step.

Is this to save a couple lines of typing?

In any case it would be nice to have the option of building separately? 
I haven't tried it, but is it as easy as just using without-python in 
.configure, then running setup.py after building and installing GDAL?

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov