From sebastic at xs4all.nl Thu Sep 1 09:23:56 2016 From: sebastic at xs4all.nl (Sebastiaan Couwenberg) Date: Thu, 1 Sep 2016 16:23:56 +0200 Subject: [Geotiff] AC_CHECK_HEADERS(geotiff/geotiff.h) fails for libgeotiff 1.4.2 Message-ID: <807f7021-ba6d-7eee-c1e5-60ab0c25a41e@xs4all.nl> Between RC2 and 1.4.2 final geotiff.h was changed to include 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 From even.rouault at spatialys.com Thu Sep 1 09:38:47 2016 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 1 Sep 2016 16:38:47 +0200 Subject: [Geotiff] AC_CHECK_HEADERS(geotiff/geotiff.h) fails for libgeotiff 1.4.2 In-Reply-To: <807f7021-ba6d-7eee-c1e5-60ab0c25a41e@xs4all.nl> References: <807f7021-ba6d-7eee-c1e5-60ab0c25a41e@xs4all.nl> Message-ID: <201609011638.48055.even.rouault@spatialys.com> 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 > 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 From even.rouault at spatialys.com Thu Sep 1 11:14:35 2016 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 1 Sep 2016 18:14:35 +0200 Subject: [Geotiff] AC_CHECK_HEADERS(geotiff/geotiff.h) fails for libgeotiff 1.4.2 In-Reply-To: <75e1534f-87fc-0c53-852f-712cac48c084@sri.com> References: <807f7021-ba6d-7eee-c1e5-60ab0c25a41e@xs4all.nl> <201609011638.48055.even.rouault@spatialys.com> <75e1534f-87fc-0c53-852f-712cac48c084@sri.com> Message-ID: <201609011814.35526.even.rouault@spatialys.com> 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 , > 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 > > or > > -I/usr/include/libgeotiff + #include > > 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 > >> 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 From sebastic at xs4all.nl Thu Sep 1 11:38:49 2016 From: sebastic at xs4all.nl (Sebastiaan Couwenberg) Date: Thu, 1 Sep 2016 18:38:49 +0200 Subject: [Geotiff] AC_CHECK_HEADERS(geotiff/geotiff.h) fails for libgeotiff 1.4.2 In-Reply-To: <201609011814.35526.even.rouault@spatialys.com> References: <807f7021-ba6d-7eee-c1e5-60ab0c25a41e@xs4all.nl> <201609011638.48055.even.rouault@spatialys.com> <75e1534f-87fc-0c53-852f-712cac48c084@sri.com> <201609011814.35526.even.rouault@spatialys.com> Message-ID: <6c301f09-1b43-ee42-94a4-100e4bb56c00@xs4all.nl> 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 From sebastic at xs4all.nl Thu Sep 1 14:06:23 2016 From: sebastic at xs4all.nl (Sebastiaan Couwenberg) Date: Thu, 1 Sep 2016 21:06:23 +0200 Subject: [Geotiff] AC_CHECK_HEADERS(geotiff/geotiff.h) fails for libgeotiff 1.4.2 In-Reply-To: <6c301f09-1b43-ee42-94a4-100e4bb56c00@xs4all.nl> References: <807f7021-ba6d-7eee-c1e5-60ab0c25a41e@xs4all.nl> <201609011638.48055.even.rouault@spatialys.com> <75e1534f-87fc-0c53-852f-712cac48c084@sri.com> <201609011814.35526.even.rouault@spatialys.com> <6c301f09-1b43-ee42-94a4-100e4bb56c00@xs4all.nl> Message-ID: <3e1ceb6b-f031-eddc-2761-812d175436f8@xs4all.nl> 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