Build issues with #include <geotiff.h> (vs #include "geotiff.h")

[rouault]

Reported by Sebastiaan Couwenberg in ​http://lists.maptools.org/pipermail/geotiff/2016-September/000816.html Between RC2 and 1.4.2 final geotiff.h was changed to include <geo_config.h> instead of "geo_config.h".

This causes the librasterlite2 configure to fail because it cannot find geo_config.h any more, because the Debian package installs the geotiff headers in /usr/include/geotiff instead of /usr/include.

I think the change should be reverted at least for geotiff.h, I'm not sure if the change in cpl_serv.h should be reverted too.

These changes were committed in r2736 to fix build issues on Windows, will reverting to #include "geo_config.h" reintroduce the build failures on Windows? If so, we should probably deal with this in Debian by specifying the custom include path used by the libgeotiff package.""" """

Charles Karney confirms that reverting to #include "geotiff.h" is OK for now : """ Yes, this change (reverting to #include "geo_config.h" in 1.4.2) works OK with Windows. Here are the "" vs <> issues in this case:

Pro <>: If users mix in-source builds on one platform with out-of-source builds on another platform, then "" will pick up the version of geo_config.h for the wrong platform. I notice that out-of-source autoconf builds don't work for libgeotiff, potentially exacerabating this problem. (This should probably be fixed at some point.) You might argue that anyone doing such inter-leaved builds is asking for trouble. (And, of course, removing geo_config.h from the source distribution helped.)

Pro "": If a user of libgeotiff uses #include <libgeotiff/geotiff.h>, then <> won't find geo_config.h in the same directory (unless the preprocessor is also told -I/usr/include/libgeotiff).

The second point is potentially troublesome (as noted by Bas) since some distributions install the include files in /usr/include/libgeotiff and there's no definitive guidance as to whether to use

-I/usr/include + #include <libgeotiff/geotiff.h>

or

-I/usr/include/libgeotiff + #include <geotiff.h>

The current install policies for libgeotiff (cmake + autoconf) suggest that the latter form is expected. I would say that the former is a better practice; unfortunately transitioning the installed base to this convention would be difficult. Compounding the problem, Debian and Fedora choose different include directories (geotiff vs libgeotiff).

Short term, I recommend:

(1) revert to

#include "geo_config.h"

(2) make out-of-source autoconf builds work

(3) document that in-source builds (either with cmake or autoconf) are not supported (possibly even disable them). """