[postgis-devel] PSC Vote: Stop installing liblwgeom INCLUDES in system

Greg Troxel gdt at lexort.com
Wed Nov 28 09:36:54 PST 2018


"Regina Obe" <lr at pcorp.us> writes:

>> If it's used semantically like a library -- which it really seems to be
>> -- you should allow dynamic linking within the build.  You are kludging
> around
>> lack of a design for managing multiple versions, and adding more
>> maintenance headaches.  So -1 from me, which I realize doesn't really
> count.
>> 
> [Regina Obe] 
> Not sure what you mean by used like a library.  
> The original reason why we had it segmented was because it was easier to
> test that way via CUNIT.
> Then later this segmentation proved a little useful when we introduced
> raster.
>
> To me it's more a header only library that can be detached from Postgres for
> ease of testing.
>
> To me it's just a pile of shared code across the different extensions
> postgis/ postgis sfcgal / postgis raster / postgis topology

That's the definition of a library :-)

> And in fact like I said each piece only uses bits of it -- thus it's a pile
> of code. 

That is also part of what library means.

> postgis will not need it bound to sfcgal, but will need it bound to GEOS
> SFCGAL needs a variant that includes SFCGAL hooks
> postgis topology needs it only bound to GEOS
> postgis raster doesn't need the GEOS part at all.

In the modern world where almost all use of any successful program is
via packaging systems, having other parts of postgis also depend
(theoretically unnecessarily) on things that other parts actually depend
on does not hurt.

As I see it you are railing against established software norms because
postgis is trying to support multiple installations without really
having a plan.

(ok on your opininon that rtopo not being viable in postgis - just
seemed worth bringing up)


More information about the postgis-devel mailing list