Support Proj 6 / 7 about mb-system

[schwehr]

@dwcaress , Look in the config.log and there should be info on what configure actually tried and the results. Please post that part of the log here. I'm not currently using proj 6 or mac osx for dev right now.

[dwcaress]

Kurt, Thanks - I’ve now discovered that my build environment is broken more generally - the PROJ6 issue is a symptom, not the central issue. My autoconf isn’t working for X11 header files either. I’m reinstalling a number of things and will try again. Thanks, Dave

…

On Apr 23, 2019, at 1:22 PM, Kurt Schwehr ***@***.***> wrote: Moving discussion from #84 to here for PROJ. Proj 6 introduces a new API by Even R. via the GDAL Barn Raising project. In Proj 6, the old way is allowed with a #define, but that will be going away in the next major version. This is a place to discuss handling the Proj 6 API. I’m currently having fits with PROJ6 - autoconf is now failing to recognize proj_api.h even when the -DACCEPT_USE_OF_DEPRECATED_PROJ_API_H is explicitly in the CFLAGS used by the AC_CHECK_HEADER() test - this workaround was working up to this morning. I’ve no idea if it broke due to a homebrew update or an Apple update. Any ideas on forcing autoconf to behave? The file is there: Haxby:mbsystem caress$ ll /usr/local/opt/proj/include/proj_api.h -rw-r--r--@ 1 caress staff 8346 Feb 26 13:09 /usr/local/opt/proj/include/proj_api.h With the PROJ6 release header file now nastily requires that the environment variable ACCEPT_USE_OF_DEPRECATED_PROJ_API_H be defined. I do that in my code easily enouugh, but for the purposes of the autoconf AC_CHECK_HEADER() test I explicitly add this to what ought to be the operative CFLAGS: dnl PROJ header location specified: $libproj_CPPFLAGS - check if proj_api.h is there... AS_ECHO(["PROJ header location specified: $libproj_CPPFLAGS - check if proj_api.h is there..."]) save_CPPFLAGS=$CPPFLAGS save_CFLAGS=$CFLAGS CPPFLAGS="$CPPFLAGS $libproj_CPPFLAGS" CFLAGS="$CFLAGS $libproj_CPPFLAGS -DACCEPT_USE_OF_DEPRECATED_PROJ_API_H" AC_CHECK_HEADER(proj_api.h, [PROJ_SETTING=yes], [PROJ_SETTING=no],) CPPFLAGS=$save_CPPFLAGS CFLAGS=$save_CFLAGS if test "$PROJ_SETTING" = "no"; then AC_MSG_ERROR([Did not find PROJ headers according to --with-proj-include - check the installation!]) fi What I get when I run the configure script is: PROJ header location specified: -I/usr/local/opt/proj/include - check if proj_api.h is there... checking proj_api.h usability... no checking proj_api.h presence... no checking for proj_api.h... no configure: error: Did not find PROJ headers according to --with-proj-include - check the installation! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

---------------------------------------------------- David W. Caress Principal Engineer Seafloor Mapping Lab Monterey Bay Aquarium Research Institute 7700 Sandholdt Road Moss Landing, CA 95039 [email protected] http://www.mbari.org/~caress/ Phone: [phone]

[dwcaress]

Kurt, The problem turned out to result from adding AC_LANG([C++]) to the configure_ac file. Removing that line and leaving just AC_LANG(C) allows the core MB-System to build as usual, but the new testing code you added fails. Of course, this is all on a Mac with the llvm compiler suite included with Xcode. I am guessing that this all works fine for you on some sort of Linux. What version of autotools are you using? Cheers, Dave Examples of the build failure in googletest include: haxby:googletest caress$ !! make depbase=`echo src/gtest-all.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../src/mbio -I. -I./include -DGTEST_HAS_PTHREAD=0 -g -O2 -MT src/gtest-all.lo -MD -MP -MF $depbase.Tpo -c -o src/gtest-all.lo src/gtest-all.cc &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src/mbio -I. -I./include -DGTEST_HAS_PTHREAD=0 -g -O2 -MT src/gtest-all.lo -MD -MP -MF src/.deps/gtest-all.Tpo -c src/gtest-all.cc -fno-common -DPIC -o src/.libs/gtest-all.o In file included from src/gtest-all.cc:38: In file included from ./include/gtest/gtest.h:62: In file included from ./include/gtest/internal/gtest-internal.h:40: ./include/gtest/internal/gtest-port.h:838:12: error: no member named 'make_tuple' in namespace 'std' using std::make_tuple; ~~~~~^ ./include/gtest/internal/gtest-port.h:839:12: error: no member named 'tuple' in namespace 'std' using std::tuple; ~~~~~^ ./include/gtest/internal/gtest-port.h:942:3: warning: deleted function definitions are a C++11 extension [-Wc++11-extensions] GTEST_DISALLOW_ASSIGN_(RE); ^ ./include/gtest/internal/gtest-port.h:684:34: note: expanded from macro 'GTEST_DISALLOW_ASSIGN_' void operator=(type const &) = delete ^ ./include/gtest/internal/gtest-port.h:985:3: warning: deleted function definitions are a C++11 extension [-Wc++11-extensions] GTEST_DISALLOW_COPY_AND_ASSIGN_(GTestLog); ^ ./include/gtest/internal/gtest-port.h:689:24: note: expanded from macro 'GTEST_DISALLOW_COPY_AND_ASSIGN_' type(type const &) = delete; \ ^ ./include/gtest/internal/gtest-port.h:985:3: warning: deleted function definitions are a C++11 extension [-Wc++11-extensions] ./include/gtest/internal/gtest-port.h:690:3: note: expanded from macro 'GTEST_DISALLOW_COPY_AND_ASSIGN_' GTEST_DISALLOW_ASSIGN_(type) ^ ./include/gtest/internal/gtest-port.h:684:34: note: expanded from macro 'GTEST_DISALLOW_ASSIGN_' void operator=(type const &) = delete ^ ./include/gtest/internal/gtest-port.h:2133:2: error: expected expression [[noreturn]] inline void Abort() { abort(); } ^ ./include/gtest/internal/gtest-port.h:2133:14: error: expected unqualified-id [[noreturn]] inline void Abort() { abort(); } ^ In file included from src/gtest-all.cc:38: In file included from ./include/gtest/gtest.h:62: ./include/gtest/internal/gtest-internal.h:122:48: warning: default template arguments for a function template are a C++11 extension [-Wc++11-extensions] int>::type = 0> ^ ~ ./include/gtest/internal/gtest-internal.h:452:3: warning: deleted function definitions are a C++11 extension [-Wc++11-extensions] GTEST_DISALLOW_COPY_AND_ASSIGN_(TestFactoryBase); ^ ./include/gtest/internal/gtest-port.h:689:24: note: expanded from macro 'GTEST_DISALLOW_COPY_AND_ASSIGN_' type(type const &) = delete; \ ^ In file included from src/gtest-all.cc:38: In file included from ./include/gtest/gtest.h:62: ./include/gtest/internal/gtest-internal.h:452:3: warning: deleted function definitions are a C++11 extension [-Wc++11-extensions] ./include/gtest/internal/gtest-port.h:690:3: note: expanded from macro 'GTEST_DISALLOW_COPY_AND_ASSIGN_' GTEST_DISALLOW_ASSIGN_(type) ^ ./include/gtest/internal/gtest-port.h:684:34: note: expanded from macro 'GTEST_DISALLOW_ASSIGN_' void operator=(type const &) = delete ^

On Apr 23, 2019, at 1:26 PM, caress ***@***.***> wrote: Kurt, Thanks - I’ve now discovered that my build environment is broken more generally - the PROJ6 issue is a symptom, not the central issue. My autoconf isn’t working for X11 header files either. I’m reinstalling a number of things and will try again. Thanks, Dave > On Apr 23, 2019, at 1:22 PM, Kurt Schwehr ***@***.***> wrote: > > Moving discussion from #84 to here for PROJ. > > Proj 6 introduces a new API by Even R. via the GDAL Barn Raising project. In Proj 6, the old way is allowed with a #define, but that will be going away in the next major version. This is a place to discuss handling the Proj 6 API. > > I’m currently having fits with PROJ6 - autoconf is now failing to recognize proj_api.h even when the -DACCEPT_USE_OF_DEPRECATED_PROJ_API_H is explicitly in the CFLAGS used by the AC_CHECK_HEADER() test - this workaround was working up to this morning. I’ve no idea if it broke due to a homebrew update or an Apple update. Any ideas on forcing autoconf to behave? > > The file is there: > Haxby:mbsystem caress$ ll /usr/local/opt/proj/include/proj_api.h > -rw-r--r--@ 1 caress staff 8346 Feb 26 13:09 /usr/local/opt/proj/include/proj_api.h > > With the PROJ6 release header file now nastily requires that the environment variable ACCEPT_USE_OF_DEPRECATED_PROJ_API_H be defined. I do that in my code easily enouugh, but for the purposes of the autoconf AC_CHECK_HEADER() test I explicitly add this to what ought to be the operative CFLAGS: > > dnl PROJ header location specified: $libproj_CPPFLAGS - check if proj_api.h is there... > AS_ECHO(["PROJ header location specified: $libproj_CPPFLAGS - check if proj_api.h is there..."]) > save_CPPFLAGS=$CPPFLAGS > save_CFLAGS=$CFLAGS > CPPFLAGS="$CPPFLAGS $libproj_CPPFLAGS" > CFLAGS="$CFLAGS $libproj_CPPFLAGS -DACCEPT_USE_OF_DEPRECATED_PROJ_API_H" > AC_CHECK_HEADER(proj_api.h, [PROJ_SETTING=yes], [PROJ_SETTING=no],) > CPPFLAGS=$save_CPPFLAGS > CFLAGS=$save_CFLAGS > if test "$PROJ_SETTING" = "no"; then > AC_MSG_ERROR([Did not find PROJ headers according to --with-proj-include - check the installation!]) > fi > > What I get when I run the configure script is: > > PROJ header location specified: -I/usr/local/opt/proj/include - check if proj_api.h is there... > checking proj_api.h usability... no > checking proj_api.h presence... no > checking for proj_api.h... no > configure: error: Did not find PROJ headers according to --with-proj-include - check the installation! > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread. >

---------------------------------------------------- David W. Caress Principal Engineer Seafloor Mapping Lab Monterey Bay Aquarium Research Institute 7700 Sandholdt Road Moss Landing, CA 95039 [email protected] http://www.mbari.org/~caress/ Phone: [phone]

[schwehr]

None of my builds are with PROJ 6 yet.

I'm on a variant of debian testing for development:

autoconf --version
autoconf (GNU Autoconf) 2.69
automake --version
automake (GNU automake) 1.15.1
libtool --version
libtool (GNU libtool) 2.4.6
gcc --version
gcc (Debian 7.3.0-15) 7.3.0

And it's working great with docker on travis using ubuntu 19.04 and proj somewhere before 6... I think it's 5.2.0: https://launchpad.net/ubuntu/disco/+source/proj