Re: Moving GDAL GRASS driver in a dedicated repository ?

--===============0228344263897805808==
Content-Type: multipart/alternative; boundary="000000000000405f6905d17ae64a"

--000000000000405f6905d17ae64a
Content-Type: text/plain; charset="UTF-8"

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 <[email protected]>
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
> [email protected]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>

--000000000000405f6905d17ae64a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"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 regula=
r 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 work=
around for this circular dependency, I agree that a dedicated repository ma=
kes sense.</div><div><br></div><div>I personally don&#39;t use the GDAL GRA=
SS 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=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Nov 18, 2021=
 at 7:13 PM Even Rouault &lt;<a href=3D"mailto:[email protected]">=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,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&#39;t try this...)<br>
<br>
This driver is a bit odd in the sense that there&#39;s a cyclic dependency =
<br>
to work around, as GRASS links to GDAL , but the GDAL GRASS driver needs <b=
r>
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&#39;s also the <br>
possibility to rebuild GDAL with the GRASS driver builtin in libgdal, <br>
but that&#39;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 <b=
r>
ensure. I&#39;m not sure if that&#39;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=3D"https://github.com/OSGeo/gdal/tree/master/frmts/grass/pkg" rel=
=3D"noreferrer" target=3D"_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 <b=
r>
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=3D"http://www.spatialys.com" rel=3D"noreferrer" target=3D"_blank">h=
ttp://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">gdal-dev@list=
s.osgeo.org</a><br>
<a href=3D"https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel=3D"norefe=
rrer" target=3D"_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</=
a><br>
</blockquote></div></div>

--000000000000405f6905d17ae64a--

--===============0228344263897805808==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

--===============0228344263897805808==--