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

[Even Rouault]

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 
> <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
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20220322/b11cbe9f/attachment.html>