On Fri, 15 Dec 2023, Even Rouault via gdal-dev wrote:
If the scope of this were to unvendor just these four (libjpeg, libpng,
zlib, giflib), I think it is enough to start, but it brings up the question
of whether or not JPEG, PNG, and GIF support are hard dependencies in GDAL
afterward. They're always available no matter how you build now, so would
we make them hard dependencies or relax them to optional after unvendoring?
I assume zlib would move to a hard dependency of GDAL.
I would let libjpeg, libpng, giflib, liblerc as optional dependencies. Our
CMake scripts already handle them as optional. Someone doing a GDAL build
only for vector might want to skip them.
But strongly recommended at least for libjpeg and libpng, since beyond being
standalone formats, they are also used for example for GeoPackage, MBTiles,
MRF, OGCAPI/WMS/WMTS, etc.
Yes zlib would move to a hard dependency, like PROJ (and if you build PROJ
with libtiff or libcurl support, you must certainly already have zlib as it
is a canonical dependency of those). There are lots of places in the code
base where we assume deflate compression/decompression to be available.
I don't see a problem but libpng also uses zlib. Do we need to
do anything to ensure that gdal uses the same zlib as libpng ?
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev