Closed thbeu closed 3 months ago
it would be appreciated to also have a new stand-alone release of shapelib containing theses fixes
I'm making a mental note of that, but the latest shapelib release is quite recent, so this will wait for a couple months at least. This will give it the opportunity to be more tested through GDAL
What about using shapelib as submodule within gdal?
I'm not sure of the impact of git submodules to the production of standalone release tarballs.
Or pulling shapelib otherwise else?
The current setup works well enough for me/GDAL. I'm not that keen on complicating/sophisticating it. Shapelib used to be a slow paced project, mostly driven by GDAL induced changes, so manual updates are fine. I sound so much as an old-timer :-) :-)
Thanks for the honest reply.
this will wait for a couple months at least
I really believe it should be the other way round. An "uber" project as gdal should get its dependencies from proper released versions.
I'm not sure of the impact of git submodules to the production of standalone release tarballs.
Build scripts require one additional step after cloning and descending into the cloned directory. That's it.
git submodule update --init
The current setup works well enough for me/GDAL.
Right. No urgent need to change then. It just feels not natural.
Some four months later I wonder what's your feeling regarding maturity of shapelib master?
v1.6.1RC1 published: https://lists.osgeo.org/pipermail/shapelib/2024-August/000652.html
v1.6.1RC2 published: https://lists.osgeo.org/pipermail/shapelib/2024-August/000653.html
shapelib 1.6.1 is released: https://lists.osgeo.org/pipermail/shapelib/2024-August/000656.html
Now that gdal 3.8.5 is released and bundles the latest shapelib fixes, it would be appreciated to also have a new stand-alone release of shapelib containing theses fixes. Thanks.
By the way, this kind of dependency management seems odd actually. What about using shapelib as submodule within gdal? Or pulling shaplib otherwise else?