[Geotiff] AC_CHECK_HEADERS(geotiff/geotiff.h) fails for libgeotiff 1.4.2

[Even Rouault]

Thanks for the feedback. I've done the partial revert per 
https://trac.osgeo.org/geotiff/ticket/81


> 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).
> 
> On 09/01/16 10:38, Even Rouault wrote:
> > Charles,
> > 
> > Could you confirm if reverting back to #include "geo_config.h" in
> > geotiff.h and cpl_serv.h cause issues on Windows ? I think you suggested
> > using <> instead of "" to avoid including the wrong geo_config.h in case
> > there would have been one in the source tree, but I've also fixed that
> > issue by not including the generated geo_config.h with "make dist".
> > 
> > Even
> > 
> >> 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.
> >> 
> >> Kind Regards,
> >> 
> >> Bas

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