Figure out and approve library dependency strategy.

[bnordgren]

Description

Currently, the "postgis" and "raster" libraries are in parallel, having no dependency relationship between them. Both libraries depend on liblwgeom for common code, but liblwgeom does not contain any postgresql-aware code (e.g., memory context, etc.) There is no place, therefore, for common code which needs to be postgresql aware.

Lack of such a mechanism is blocking #1053 and #1058, which attempt to implement the dependency represented by the dashed line in the following figure:

As I see it, there are four candidate solutions:

1. Duplicate the common code in postgis/ and raster/ (ick)
2. Figure out how to correctly make one shared library depend on another, when the linking happens before the first shared library is installed. (e.g., shared library is moved after something links against it.)
3. Create a new static library which contains common code that is postgresql-aware.
4. Make libpostgis and libraster be static, and create one merged shared library containing both of them.

References

Helpful (hopefully) web links…

• ​Libtool manual on inter-library dependencies
• ​Autoconf, automake, and libtool documentation

[pracine]

Could you describe why you need such a dependency? Which functionality do you need from libpostgis?

[bnordgren]

The immediate need is described at length on #1058, even though it applies more directly to #1053.

In essence, I want access to the cache of projections. The code uses postgresql memory context stuff and queries the spatial_ref_sys table. Hence, it cannot go into liblwgeom, as that is not supposed to be tied to postgresql.

[pracine]

Is it because you want to reproject some geometry or raster on the fly to the srid of another geometry or raster in order to do some operation implying both?

[bnordgren]

Essentially. But without actually resampling. GDAL has an "image to image" transformer, which calculates the (i,j) index of one image using the (i,j) index of a second image. This needs the projections (SRS) of the two images.

However, once a strategy is figured out, it has much wider applicability than this first application. Raster suddenly has access to all Postgis functionality at the C level.

[bnordgren]

Tentatively adopting strategy three, above. See the patch on #1053 for the creation of a libcommon static library which can be used by code in both raster and postgis.

[bnordgren]

Dependencies suggested by option 3 are illustrated by

Note liblwgeom is the only library which does not depend on one of the others.

[strk]

I think we're pretty much settled about libs dependencies for the time being.