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

[Markus Metz]

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.rouault at 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-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20211123/c3577845/attachment.html>