[postgis-devel] liblwgeom.so

[Mark Cave-Ayland]

On 09/09/11 18:33, Paul Ramsey wrote:

> So, back in mid-month, strk asked:
>
> "Do you agree on having liblwgeom installed systemwide and dynamically
> linked starting with PostGIS 2.0 ?"
>
> And there followed, oddly enough, a lot of discussion about the
> mechanics of doing it and no discussion at all about the wisdom of
> doing it. I would like to backtrack a little and talk about why it
> gives me a case of the heebie jeebies.
>
> * Our build is already getting complexer and complexer, and this adds
> more complexity, and another autotool to our world.
> * Breaking our install into components (this library here, these tools
> that depend on it there) adds to the number of places an install can
> fail (ha ha! you can't find the library! (note how many times this
> happens to us already with libgeos!)) even though in theory this stuff
> always "just works"

I think that these are both invalid arguments given the amount of 
additional build dependencies that the raster code has added. After the 
first raster commit, even here on Linux I had to spend quite a bit of 
time updating my build environment to get everything back to normal. 
Taking your argument further, we could then also argue that we should be 
doing static links with GEOS and PROJ.4 in order to prevent dependency 
issues, but then again I don't see too many complaints about this on the 
mailing list so I don't think we are going to see the majority of the 
issues in this area.

> * We are a PgSQL extension, not a third-party library. If this
> actually "succeeds" in getting people using liblwgeom, it also "fails"
> in that now we have to, in addition to doing our own work as PostGIS
> developers, ensure we don't break other people's work. If we do change
> things all the time and people don't use us, then we don't "succeed",
> so the "let other people use liblwgeom" argument fails.

At the moment, it's something we use not only for code but to help us 
test and debug individual functions and use internally within PostGIS 
(finding a memory leak in liblwgeom is trivial compared to a PostgreSQL 
backend). It's not something that I feel we should immediately say "yes, 
we support this" outside of PostGIS, but as Bryce suggests we shouldn't 
necessarily stop people from making use of it if they have a use case.

I would suggest that rather than installing in $libdir, we should place 
liblwgeom and any other related libraries in $pkglibdir to indicate that 
this is more of a private library rather than explicitly public.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs