[GRASS-dev] Moving GDAL GRASS driver in a dedicated repository ?

[Even Rouault]

Hi,

(writing to both GDAL and GRASS lists)

Working on the transition to CMake as the GDAL build system, the 
particular status of the GRASS driver in GDAL raised my attention.

(The following is based on my understanding. It has been ages since I 
didn't try this...)

This driver is a bit odd in the sense that there's a cyclic dependency 
to work around, as GRASS links to GDAL , but the GDAL GRASS driver needs 
to be linked against GRASS.

So the usual procedure is:

- build GDAL without the GRASS driver

- build GRASS against GDAL

- build the GDAL GRASS driver from the separate gdal-grass tarball that 
GDAL distributes along its main tarball.

With the current GDAL autoconf build system, there's also the 
possibility to rebuild GDAL with the GRASS driver builtin in libgdal, 
but that's a bit odd, since you need to make sure that this new libgdal 
is the one that GRASS will link against at runtime, otherwise chaos will 
ensure. I'm not sure if that's used. This is typically something I would 
*not* want to support in the new GDAL cmake build.

All in all, given the particular nature of that driver, I believe it 
would be better in a dedicated repository, with its standalone build 
scripts, whose initial version could be just the ones of 
https://github.com/OSGeo/gdal/tree/master/frmts/grass/pkg, or evolve to 
CMake or whatever the maintainers of that driver would prefer. I believe 
this would make the situation clearer.

Opinions ? and people interested in setting up that dedicated repository ?

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.