Build issues with #include <geo_config.h> (vs #include "geo_config.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).

[rouault]

trunk r2739 'geotiff.h cpl_serv.h: Partial revert of r2736 to revert back including "geo_config.h" (fixes #81)'