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.roua...@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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
