[gdal-dev] building against external tiff/geotiff sources ?

Even Rouault even.rouault at spatialys.com
Sun Mar 5 03:05:36 PST 2023


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.



More information about the gdal-dev mailing list