Hi,
currently some interesting features (for example jxl compression in
tiff) requires one to build against internal tiff/geotiff - after
looking at the code, from my understanding this is because the gtiff
driver reaches to internal tiff functions not present in the public API,
which (to me) is a valid reason. Afaict the bundled copies dont diverge
from upstream, since even maintains both sides in parallel.
The JXL codec is the only functionality that currently requires using
the internal copy of libtiff, not because there's anything special in
it, but because TIFF codecs require access to private headers of
libtiff. The reason for the JXL codec being in GDAL only is that it
makes it easier for early adopters to assess adequacy of this codec for
GDAL purposes without requiring first to have it accepted in libtiff
(there was a similar situation a few years ago with the LERC codec). The
medium/long term plan is to migrate it to libtiff, presumably once
libjxl has reached 1.0 and API stability.
Thus, two questions:
- in the long run, are there plans to allow building against external
libtiff/libgeotiff libraries/packages for all features 'restricted' to
the internal copies of those (eg stop relying on internal funcs, or put
those in the public API), or that'd be too much a maintainance hell ?
Cf above. Relying on internal libtiff funcs for the JXL codec is by
design/compulsory.
- would it be possible to allow building against external
libtiff/libgeotiff _sources_ ? this way i'd still be able to apply
fixes to one place, but i also suppose that'll require a tight version
dependency on those..
Everything is possible, but I don't think we want to complicate the
build system with that extra possibility.
So yes packages that follow rules of not using vendored libraries can't
use the JXL codec for now. Hopefully that's just a transient state.
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
