<div dir="ltr"><div>Hi Even,</div><div><br></div><div>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!</div><div><br></div><div>Considering the workaround for this circular dependency, I agree that a dedicated repository makes sense.</div><div><br></div><div>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.</div><div><br></div><div>Markus M<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 18, 2021 at 7:13 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
(writing to both GDAL and GRASS lists)<br>
<br>
Working on the transition to CMake as the GDAL build system, the <br>
particular status of the GRASS driver in GDAL raised my attention.<br>
<br>
(The following is based on my understanding. It has been ages since I <br>
didn't try this...)<br>
<br>
This driver is a bit odd in the sense that there's a cyclic dependency <br>
to work around, as GRASS links to GDAL , but the GDAL GRASS driver needs <br>
to be linked against GRASS.<br>
<br>
So the usual procedure is:<br>
<br>
- build GDAL without the GRASS driver<br>
<br>
- build GRASS against GDAL<br>
<br>
- build the GDAL GRASS driver from the separate gdal-grass tarball that <br>
GDAL distributes along its main tarball.<br>
<br>
With the current GDAL autoconf build system, there's also the <br>
possibility to rebuild GDAL with the GRASS driver builtin in libgdal, <br>
but that's a bit odd, since you need to make sure that this new libgdal <br>
is the one that GRASS will link against at runtime, otherwise chaos will <br>
ensure. I'm not sure if that's used. This is typically something I would <br>
*not* want to support in the new GDAL cmake build.<br>
<br>
All in all, given the particular nature of that driver, I believe it <br>
would be better in a dedicated repository, with its standalone build <br>
scripts, whose initial version could be just the ones of <br>
<a href="https://github.com/OSGeo/gdal/tree/master/frmts/grass/pkg" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/tree/master/frmts/grass/pkg</a>, or evolve to <br>
CMake or whatever the maintainers of that driver would prefer. I believe <br>
this would make the situation clearer.<br>
<br>
Opinions ? and people interested in setting up that dedicated repository ?<br>
<br>
Even<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div></div>