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.
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
