[postgis-devel] liblwgeom.so

[Paul Ramsey]

Mark,
Why do you *want* to do this?
P.

On Mon, Sep 12, 2011 at 3:47 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> 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
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>