[gdal-dev] 'HOST_FILLORDER': macro redefinition

[Even Rouault]

> If it were redefining to the same value, that would be one thing, but since
> it is redefining to another value, it makes you wonder 1) why is it coming
> in differently, and 2) which value should it be?

Paul, overall this doesn't seem critical as the only real use of 
HOST_FILLORDER in all GDAL, libtiff and libgeotiff code bases in in libtiff 
TIFFOpen() function when the esoteric 'H' open flag is used, and that one is 
likely rarely used (not used by GDAL typically). So you could just #undef 
HOST_FILLORDER between the 2 #include to silence the warning.

Tamas, how is tiffconf.h in gisinternals produced, which has this unexpected 
#define HOST_FILLORDER FILLORDER_MSB2LSB (should be LSB2MSB for Intel 
platforms) ? Is this the result of cmake ? I guess so, as it doesn't seem to 
be in sync with the tiffconf.vc.h that is also provided and used by nmake 
builds. That would mean that there's an issue in the CMake configuration step 
with VS builds:
https://gitlab.com/libtiff/libtiff/blob/master/CMakeLists.txt#L394

Actually, I just found a CI with CMake + Windows at
https://ci.appveyor.com/project/rleigh-codelibre/libtiff-didfs/builds/
25846668/job/ory5w098j8wcij9x
where I can see:

[00:02:58] -- CMAKE_HOST_SYSTEM_PROCESSOR set to AMD64
[00:02:58] -- HOST_FILLORDER set to FILLORDER_MSB2LSB

So this seems to be a case sensitivity issue when comparing AMD64 vs amd64.
I've just submitted
https://gitlab.com/libtiff/libtiff/merge_requests/87
to fix this.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com