2021.04.14 16:48 "[Tiff] 4.3.0 release ?", by Even Rouault

2021.04.14 20:47 "Re: [Tiff] 4.3.0 release ?", by Even Rouault

Is that line in ' tif_jpeg_12.c ' really necessary? The header and library for 12-bit jpeg are correctly found by specifying their locations on the cmake command line.

yes, it is. Otherwise you're likely going to use symbols of the 8-bit libjpeg. It might build fine, but at runtime, you won't be able to read 12-bit jpeg compressed files.

I understand. In this case, shouldn't the build process *prefer* the just-produced 'tif_config.h' file located *inside* the libtiff build dir?

Consider the following scenario:

Suppose I never needed 12-bit jpeg for my work. I have a general 'build' directory containing general 'lib' and 'include' directories. This one contains a 'tif_config.h' file, coming from previous builds of libtiff and used by several other projects needing libtiff. It doesn't contain any 12-bit jpeg instructions because I never needed the functionality.

Now I find that I need 12-bit jpeg for a particular project. I have my 12-bit lib and headers on a specific different location, which I specify on the cmake command line. The cmake configuration phase produces a new tif_config.h file containing the appropriate instructions for 12-bit jpeg, which it places inside 'builddir/libtiff/libtiff'. The build process then proceeds to use another 'tif_config.h' file and not the one it just created?

Does this mean that I have to delete, move, rename or otherwise conceal any 'tif_config.h' file that might reside *outside* the libtiff build dir, lest it is used instead of the proper one? Of course I can live with that, but it seems "somewhat" odd to me...

Perhaps tweeking include orders in build scripts could help, but this is always going to be fragile... I let others potentially chim in on that. I don't think that's issue is new to recent developments

Even

http://www.spatialys.com
My software is free, but my time generally not.