<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>bumping again this topic, after feedback just received on
3.5.0alpha1.</p>
<p>For now, I'm heading to completely disable CMake build support
for the GRASS drivers in <a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/pull/5490">https://github.com/OSGeo/gdal/pull/5490</a> .
Only the existing autoconf scripts that are provided with the
plugin (if they work ?) will be usable.<br>
</p>
<p>As noted in my comments, CMake build support could potentially be
re-enabled, but just allowed the driver to be built as a plugin,
and not built-in in GDAL core lib. However that would still do a
full GDAL build, not just the driver, so this is perhaps not so
useful (a CMake build for the driver would just use an already
built GDAL and use find_package(GDAL) )<br>
</p>
<p>It would be good if someone could step up as the maintainer of
the driver in-tree, or in an external repository. Otherwise we
might just end up giving it the treatment of other drivers that
lack attention from a maintainer, ie rm -rf .<br>
</p>
<p>Even<br>
</p>
<div class="moz-cite-prefix">Le 23/11/2021 à 21:50, Markus Metz a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAG+h=FEN6Xz3z0RA+F7aWkk461POO=FVyvT34p2obG4pk3y-KA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true" class="moz-txt-link-freetext">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote>
</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>