Re: Moving GDAL GRASS driver in a dedicated repository ?
Even Rouault <[email protected]> Tue, 22 Mar 2022 19:41:19 +0100
| Newsgroups | gmane.comp.gis.gdal.devel,gmane.comp.gis.grass.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============7814884278411212010== Content-Type: multipart/alternative; boundary="------------QK0EHevPxXQxy0XHMv8Gh0hd" Content-Language: en-US This is a multi-part message in MIME format. --------------QK0EHevPxXQxy0XHMv8Gh0hd Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, bumping again this topic, after feedback just received on 3.5.0alpha1. For now, I'm heading to completely disable CMake build support for the GRASS drivers in https://github.com/OSGeo/gdal/pull/5490 . Only the existing autoconf scripts that are provided with the plugin (if they work ?) will be usable. 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) ) 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 . Even Le 23/11/2021 à 21:50, Markus Metz a écrit : > 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 > -- http://www.spatialys.com My software is free, but my time generally not. --------------QK0EHevPxXQxy0XHMv8Gh0hd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <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:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</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:[email protected]" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</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> --------------QK0EHevPxXQxy0XHMv8Gh0hd-- --===============7814884278411212010== 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 --===============7814884278411212010==--