Hi Even, IMHO it has been a bit of a luxury that the GDAL GRASS driver was allowed to exist as a regular GDAL supported format within frmts/grass. With every new release of GDAL, you (the GDAL maintainers) also released a separate new GDAL GRASS driver which was really nice of you!
Considering the workaround for this circular dependency, I agree that a dedicated repository makes sense. I personally don't use the GDAL GRASS driver at all (I just try to maintain it), but I am aware that a number of projects use the GDAL GRASS driver. Feedback from any affected projects would be helpful. Markus M On Thu, Nov 18, 2021 at 7:13 PM Even Rouault <even.roua...@spatialys.com> wrote: > 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. > > _______________________________________________ > gdal-dev mailing list > gdal-...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev