Re: [GRASS-dev] [gdal-dev] Moving GDAL GRASS driver in a dedicated repository ?
Hi Even, (summary for the lists) On Mon, May 2, 2022 at 1:38 PM Even Rouault wrote: > > Hi Markus, > > looks good to me. So maybe now you can send a pull request to remove the > drivers from OSGeo/GDAL and modify > https://gdal.org/drivers/raster/grass.html & > https://gdal.org/drivers/vector/grass.html to point to the new repo ? Yes, done and merged: https://github.com/OSGeo/gdal/pull/5671 Driver removal (done by you): https://github.com/OSGeo/gdal/pull/5672 New driver home (with CI and sime tests): https://github.com/OSGeo/gdal-grass > I'd like to issue a 3.5.0 release candidate this week. > > Even Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [gdal-dev] Moving GDAL GRASS driver in a dedicated repository ?
Hi Markus, looks good to me. So maybe now you can send a pull request to remove the drivers from OSGeo/GDAL and modify https://gdal.org/drivers/raster/grass.html & https://gdal.org/drivers/vector/grass.html to point to the new repo ? I'd like to issue a 3.5.0 release candidate this week. Even Le 28/04/2022 à 22:31, Markus Neteler a écrit : Hi Even, (back to your wish) On Thu, Nov 18, 2021 at 7:12 PM Even Rouault 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 ? Yes and finally done that: https://github.com/OSGeo/gdal-grass Hope I got it right (history is preserved, I used git filter-repo --path ogr/ogrsf_frmts/grass --path frmts/grass and then moved the remaining needed files into the toplevel directory. Hope I got it right. Markus -- http://www.spatialys.com My software is free, but my time generally not. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [gdal-dev] Moving GDAL GRASS driver in a dedicated repository ?
Hi Even, (back to your wish) On Thu, Nov 18, 2021 at 7:12 PM Even Rouault 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 ? Yes and finally done that: https://github.com/OSGeo/gdal-grass Hope I got it right (history is preserved, I used git filter-repo --path ogr/ogrsf_frmts/grass --path frmts/grass and then moved the remaining needed files into the toplevel directory. Hope I got it right. Markus -- Markus Neteler, PhD https://www.mundialis.de - free data with free software https://grass.osgeo.org https://courses.neteler.org/blog ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [gdal-dev] Moving GDAL GRASS driver in a dedicated repository ?
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 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-...@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev -- http://www.spatialys.com My software is free, but my time generally not. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [gdal-dev] Moving GDAL GRASS driver in a dedicated repository ?
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 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-...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
