[postgis-devel] liblwgeom.so, install-liblwgeom, uninstall-liblwgeom

[Sandro Santilli]

On Mon, Aug 08, 2011 at 10:56:29AM +0100, Mark Cave-Ayland wrote:
> On 06/08/11 18:57, Sandro Santilli wrote:
> 
> >As of r7701 we have 3 new rules in liblwgeom/Makefile:
> >
> >  libwgeom.so       -- Will attempt to build a shared library whose SONAME
> >                       is based on POSTGIS_MAJOR_VERSION
> >
> >  install-liblwgeom -- Will install the shared library under libdir (affected
> >                       by --prefix, --exec-prefix and --libdir, and also
> >                       honouring DESTDIR) with real-name formed by full
> >                       postgis version triplet.
> >
> >  uninstall-liblwgeom -- Will uninstall the shared library.
> >
> >None of those rules are invoked by default.
> >This is to have them for testing w/out breaking any existing use.
> >I'd love to get failure tickets for builds on non-GNU systems.
> >Even better I'd like patches :)
> >
> >Note that all postgis users (raster, postgis, cunit) are linking against
> >the static (not shared) library.
> 
> I've just taken a look at this, and I think that if we're going to
> switch from static to dynamic then we might as well just do it.
> Otherwise we're not going to get the testing we require.

Doing this w/out automake/libtool will give some headaches (linking
against the _built_, not the _installed_ library).

> I also see that in r7701 you've dropped the use of libtool - I
> really recommend against this. I know it has its own interesting
> quirks to work around, but it does have the magic to make things
> work. Interestingly enough the comment mentions libtool was dropped,
> but not why?

Libtool use was introduced in one or two commit before, so was a new
thing. I gave up after the first few difficulties in having it build
a shared library. It's easy to use libtool with automake, not so easy
using it standalone. If you want to give it a try I'm happy to see it
coming back. Or I'll get to it later, after library cleanups.

> >TODO:
> >  - Install the static library as well.
> 
> If you can get libtool to work then this bit will be handled automatically.
> 
> >  - Install an API header file (with some documentation).
> 
> Paul started some work on moving the private functions into a
> liblwgeom_internal.h file so that liblwgeom.h is just the public API
> file. It would be great to finish this section of work.

I'm trying to go on with this.
One concern is where to draw a line between what's private and what's
public. Everything private makes the best maintainable (and useless)
piece of software ;)
Seriously, one approach would be to use opaque types like GEOS C-API
does. That approach proved to be pretty stable in time. This would mean
clients of liblwgeom will only know about an opaque LWGEOM type and have
functions to serialize/deserialize it and do operations on it.
But maybe we also want points ? boxes ?

> >  - Make sure it works on other systems.
> 
> That will probably have to wait until testing :)

As with other points above, libtool would fix this too...

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html