On 3/22/22 19:41, Even Rouault wrote:
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.
The libgdal-grass Debian package uses the autoconf bits.
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 .
According to the wiki Markus and Markus are the maintainers of the GRASS
driver:
https://github.com/OSGeo/gdal/wiki/Maintainers-per-sub-system
With GRASS using non-standard library directories it doesn't work that
well as recently discussed on grass-dev:
https://lists.osgeo.org/pipermail/grass-dev/2022-February/095596.html
Removing the driver upstream and the libgdal-grass package from Debian
would make my life easier, so no objection from me.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
