AC_CHECK_HEADERS(geotiff/geotiff.h) fails for libgeotiff 1.4.2

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

AC_CHECK_HEADERS(geotiff/geotiff.h) fails for libgeotiff 1.4.2

Sebastiaan Couwenberg
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

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

Re: AC_CHECK_HEADERS(geotiff/geotiff.h) fails for libgeotiff 1.4.2

Even Rouault-2
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
_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

Re: AC_CHECK_HEADERS(geotiff/geotiff.h) fails for libgeotiff 1.4.2

Even Rouault-2
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
_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

Re: AC_CHECK_HEADERS(geotiff/geotiff.h) fails for libgeotiff 1.4.2

Sebastiaan Couwenberg
On 09/01/2016 06:14 PM, Even Rouault wrote:
> Thanks for the feedback. I've done the partial revert per
> https://trac.osgeo.org/geotiff/ticket/81

Thanks for the quick feedback, and the changes related to this issue.

I'll prepare a new libgeotiff upload for Debian with changes from r2739
included as a patch.

At the same time I'm also rebuilding all reverse dependencies again with
libgeotiff 1.4.2. to check if others projects than librasterlite2 are
affected too.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff
Reply | Threaded
Open this post in threaded view
|

Re: AC_CHECK_HEADERS(geotiff/geotiff.h) fails for libgeotiff 1.4.2

Sebastiaan Couwenberg
On 09/01/2016 06:38 PM, Sebastiaan Couwenberg wrote:

> On 09/01/2016 06:14 PM, Even Rouault wrote:
>> Thanks for the feedback. I've done the partial revert per
>> https://trac.osgeo.org/geotiff/ticket/81
>
> Thanks for the quick feedback, and the changes related to this issue.
>
> I'll prepare a new libgeotiff upload for Debian with changes from r2739
> included as a patch.
>
> At the same time I'm also rebuilding all reverse dependencies again with
> libgeotiff 1.4.2. to check if others projects than librasterlite2 are
> affected too.

The rebuilds revealed no other affected reverse dependencies of
libgeotiff in Debian, so that's good news.

I've summarized the results on the debian-gis list:

 https://lists.debian.org/debian-gis/2016/09/msg00000.html

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
Geotiff mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/geotiff