CMakeLists.txt: Fix build on modern *nix systems w/C++17

[trinitronx]

This fixes #104

• Use C++17 in CMakeLists.txt
• Use "NEW" BoostConfig.cmake policy (CMP0167)
• Change ordering of project() after cmake_minimum_required() - Similar to fix described in trivial: add .gitignore, compact CMakeLists.txt, forward declare library-dependent type #102

Note

For those who can't wait for this PR to be merged, but need a working darling-dmg on affected Arch-based distro family systems:

See this forked PKGBUILD which includes this patch

[bugaevc]

/usr/include/unicode/unistr.h and /usr/include/unicode/localpointer.h, which is where compilation fails according to #104, appear to be a part of libicu? Does libicu hard-require you to use C++17 now?

[trinitronx]

/usr/include/unicode/unistr.h and /usr/include/unicode/localpointer.h, which is where compilation fails according to #104, appear to be a part of libicu?

Yes, it looks like /usr/include/unicode/unistr.h is part of libicu (Arch package: core/icu), which is currently version 75.1:

$ pacman -Fx /usr/include/unicode/unistr.h
usr/include/unicode/unistr.h is owned by core/icu 75.1-1
$ pacman -Fx /usr/include/unicode/localpointer.h
usr/include/unicode/localpointer.h is owned by core/icu 75.1-1

Does libicu hard-require you to use C++17 now?

I'm not sure, but the errors relating to std::enable_if_t might need at least C++14:

error: ‘std::enable_if_t’ has not been declared.

Yet, when I tried using set(CMAKE_CXX_STANDARD 14), there were some other errors:

C++14 Build Log

$ mkdir build && cd build 
$ cmake ../ -DCMAKE_INSTALL_PREFIX=/usr -DWITH_TESTS=1 -DCMAKE_BUILD_TYPE=Release
-- The C compiler identification is GNU 14.2.1
-- The CXX compiler identification is GNU 14.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "2.1.1")
-- Found LibXml2: /usr/lib/libxml2.so
-- Configuring done (0.3s)
-- Generating done (0.0s)
-- Build files have been written to: /home/exampleuser/src/pub/darling-dmg/build

$ make
[  3%] Building CXX object CMakeFiles/CacheTest.dir/test/CacheTest.cpp.o
[  6%] Building CXX object CMakeFiles/CacheTest.dir/src/CacheZone.cpp.o
[  9%] Building CXX object CMakeFiles/CacheTest.dir/src/CachedReader.cpp.o
[ 12%] Building CXX object CMakeFiles/CacheTest.dir/src/Reader.cpp.o
[ 15%] Building CXX object CMakeFiles/CacheTest.dir/src/MemoryReader.cpp.o
[ 18%] Linking CXX executable CacheTest
[ 18%] Built target CacheTest
[ 21%] Building CXX object CMakeFiles/dmg.dir/src/unichar.cpp.o
In file included from /usr/include/unicode/unistr.h:39,
                 from /home/exampleuser/src/pub/darling-dmg/src/unichar.cpp:3:
/usr/include/unicode/stringpiece.h:134:23: error: ‘is_same_v’ is not a member of ‘std’; did you mean ‘is_same’?
  134 |                 (std::is_same_v<decltype(T().data()), const char*>
      |                       ^~~~~~~~~
      |                       is_same
/usr/include/unicode/stringpiece.h:134:66: error: template argument 1 is invalid
  134 |                 (std::is_same_v<decltype(T().data()), const char*>
      |                                                                  ^
/usr/include/unicode/stringpiece.h:138:17: error: expected ‘>’ before ‘)’ token
  138 |                 ) &&
      |                 ^
/usr/include/unicode/stringpiece.h:138:17: error: expected unqualified-id before ‘)’ token
In file included from /usr/include/unicode/uenum.h:25,
                 from /usr/include/unicode/ucnv.h:52,
                 from /home/exampleuser/src/pub/darling-dmg/src/unichar.cpp:4:
/usr/include/unicode/localpointer.h:561:26: error: ‘auto’ parameter not permitted in this context
  561 | template <typename Type, auto closeFunction>
      |                          ^~~~
/usr/include/unicode/localpointer.h:573:76: error: template argument 2 is invalid
  573 |     explicit LocalOpenPointer(std::unique_ptr<Type, decltype(closeFunction)> &&p)
      |                                                                            ^
/usr/include/unicode/localpointer.h:583:78: error: template argument 2 is invalid
  583 |     LocalOpenPointer &operator=(std::unique_ptr<Type, decltype(closeFunction)> &&p) {
      |                                                                              ^
/usr/include/unicode/localpointer.h:599:59: error: template argument 2 is invalid
  599 |     operator std::unique_ptr<Type, decltype(closeFunction)> () && {
      |                                                           ^
/usr/include/unicode/uenum.h:69:1: note: invalid template non-type parameter
   69 | U_DEFINE_LOCAL_OPEN_POINTER(LocalUEnumerationPointer, UEnumeration, uenum_close);
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/unicode/ucnv.h:597:1: note: invalid template non-type parameter
  597 | U_DEFINE_LOCAL_OPEN_POINTER(LocalUConverterPointer, UConverter, ucnv_close);
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [CMakeFiles/dmg.dir/build.make:76: CMakeFiles/dmg.dir/src/unichar.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:113: CMakeFiles/dmg.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

I bumped it to C++17, and then it compiled fine.

[trinitronx]

Does libicu hard-require you to use C++17 now?

@bugaevc: For what it's worth, that second set of errors when trying C++14 was also mentioning files from the icu package:

/usr/include/unicode/stringpiece.h:134:23: error: ‘is_same_v’ is not a member of ‘std’;

$ pacman -Fx /usr/include/unicode/stringpiece.h
usr/include/unicode/stringpiece.h is owned by core/icu 75.1-1

So, given that there are no standards supported by gcc's -std= between c++14 and c++17... I suppose it would be safe to assume that current versions of libicu require at least the C++ 2017 standard.

EDIT: According to the icu.unicode.org website, C++ 17 is now required for version 75

2024-04-17: ICU 75 is now available. It updates to CLDR 45 (beta blog) locale data with new locales and various additions and corrections. C++ code now requires C++17 and is being made more robust. The CLDR MessageFormat 2.0 specification is now in technology preview, together with a corresponding update of the ICU4J (Java) tech preview and a new ICU4C (C++) tech preview. See Downloading ICU > ICU 75.