build: don't write to global variable CMAKE_CXX_STANDARD

[OlivierLDff]

Instead use modern target_compile_features with cxx_std_11 (since this project is compatible with C++11 and later). More information: https://cmake.org/cmake/help/latest/command/target_compile_features.html

If user wants to access c++14/17/20 features, it is up to him to define cxx_std_ on his target. Or he can still use the old school CMAKE_CXX_STANDARD global variable.

This commit might break project relying on date writing to a global variable. If user links his target to date, his target will be promoted at least to c++11 if not specified otherwise.

[ChrisThrasher]

I like this! I recently did the same thing in fmtlib here. Don't forget you need to bump the minimum CMake version to 3.8 to ensure that this compile feature exists.

[OlivierLDff]

I like this! I recently did the same thing in fmtlib here. Don't forget you need to bump the minimum CMake version to 3.8 to ensure that this compile feature exists.

Sure done. Have a nice day.

[Tachi107]

If user wants to access c++14/17/20 features, it is up to him to define cxx_std_ on his target.

Unfortunately it is not that simple. If you compile libdate-tz in e.g. C++17 mode you cannot use it in projects targeting an older standard, as some functions are conditionally complied depending on whether std::string_view is available or not, like locate_zone(). The same applies the other way around; if you compile the .cpp file in C++11 mode and then use the headers in C++17 mode, you're code will try to link to the implementation that uses std::string_view, but the complied object only contains the std::string one so you'll get linking errors.

It might make sense to set cxx_std_17 as PUBLIC; that's what I'm planning to do in the Debian package.

Edit: alternatively, it might be better to make HAS_STRING_VIEW a public define.

[basilgello]

Maybe a crazy idea but… Can we compile both sets of functions somehow to produce libraries with string_view and string? Then we could ship the CMake configutations for every combination of parameters. I did this for kissfft, it is time consuming but doable.

[Tachi107]

Can we compile both sets of functions somehow to produce libraries with string_view and string?

Yes, it should be possible. But even then, the C++ version has to be set to cxx_std_17, otherwise the std::string_view variant cannot be possibly compiled into the library.