[postgis-devel] liblwgeom.so

[Sandro Santilli]

On Fri, Sep 9, 2011 at 1:13 PM, Paragon Corporation <lr at pcorp.us> wrote:
>
>> I know the "we know it works" argument very well, but you
>> have to draw a line between stability and innovation. Given
>> we're going 2.0 (how many things known to work we left
>> already?) it seems a good occasion to move forward to me.
>
> I'm on Paul's side on this one.  I personally would really like to get
> PostGIS 2.0 out before
> the new year.  I'm already pissed that it looks like we are going to miss
> the 9.1 release cycle.

Is the increased build complexity holding back any closeup attempt ?
Beside the libpgcommon issue, I mean...

> Innovation for innovation sake is folly.  We'll have plenty of occasion for
> this like when we
> try to introduce pgrouting in 2.1 or 2.2. This stuff doesn't require on-disk
> format change so there isn't any reason why it can't wait
> till 2.1 or 2.2 when tere would be more of a need for it.

Well, the liblwgeom "separation" was in the backlog since PostGIS 1.0 times,
isn't anything brought out at the last minute. Linking the utilities dynamically
could be postponed if it causes major issues.

> BTW - I redownloaded everything from scratch and my build is still building
> only static libraries.
> So this dynamic thing isn't happening for me anyway.

Libtool says it'll do dynamic linking when possible, static otherwise.
Maybe doesn't know how to do dynamic linking on win32 ? I've no idea.
For me doing dynamic linking for the utils was more of a way to prove
the dynamic library was working than anything else.

> Yuck.  As far as static vs. dynamic.  All else being equal, I prefer
> static unless it reduces a user's freedom to replace a newer version (e.g.
> GEOS or proj or whatever).

I didn't try but you may be able to choose that at configure time.
Standard configure switch is --disable-shared for building all static binaries.
We'll get to give the freedom to replace dynamically linked library but seemed
to early to me for doing this _now_. That's mainly due to the lack of a properly
designed public API which would then break easily, and to the unwillingness
to maintain a separate versioning scheme, which would be required so to encode
ABI/API compatibilities in the library.

So this is basically a first step, making liblwgeom more independent,
just a bit more.

> Here there is absolutely no gain since you would never mismatch the versions
> and dynamic makes it possible
> to accidentally do so.

Well, within the same installation you have the advantage (on systems where it
works) to put shared code in a shared file...

> As far as Mark's comment on saves memory.  the only place I would need
> saving memory is in PostgreSQL
> and if we can't dynamically link for postgis then there is absolutely no
> gain whatsoever.

It's a possible improvement if we get around the regress testing issue.
I've got a limited budget for liblwgeom advancements, could't do all of
API design, PGXS struggling and development of additional utilities.
Hopefully what I did can be seen as a first step toward improved
modularization.

Paul: about GEOS/OGR it happens to me that PostGIS has additional algorithms
that are not provided by either of the two. We could move them to GEOS but the
cost would be discrepancy with JTS. Could we move them to OGR ?
I'm particularly thinking about the MakeValid routine, which would
require big changes
in GEOS where you could not even build some invalid geometries, thus you'd be
unable to do the cleanup.

--strk;

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