use CMake's builtin support for C++ standard selection

[doudou]

CMake has builtin support for C++ standard selection ever since v3.1. I really think we should use this instead of the Rock macro (which, by the way, uses CMake's builtin)

See https://www.rock-robotics.org/rock-and-syskit/libraries/cpp_libraries.html#cxx_standard

[planthaber]

Wouldn't be even better to use cmakes target_compile_features function to let cmake decide which compiler to use?

"target_compile_features(mylib PRIVATE cxx_std_11)"
Means the compiler has to be aware of cxx11, to me that also means, higher is also ok.

Or even name the used features directly

https://cmake.org/cmake/help/v3.8/manual/cmake-compile-features.7.html

Btw.:We should change pocolog_cpp accordingly when we decided.

[2maz]

@doudou I considered to not using the rock_activate_cxx11 macro, but then thought:

1. it wraps cmake's current standard mechanisms and includes legacy support
2. is one statement only, if i am not mistaken we would have to set CMAKE_CXX_STANDARD_REQUIRED to prevent potential fallback behaviour
3. can (in principle at least) easier be maintained by just changing base/cmake

If we come to the conclusion that rock_activate_cxx11 macros should not be used anymore, we should first deprecate them in base/cmake - e.g. start adding a corresponding deprecation warning.

[doudou]

1. Fair enough. Now, do we want to support CMake versions older than 2014 ?
2. two statements instead of one. Is that such a great price to pay w.r.t. hiding behind layers ?
3. I'm more afraid of breakage due to our code than due to CMake's

I believe that CMake's mechanism is good enough, and that making its use explicit is for the best. The least amount of Rock-specific macros we have the better.

That leaves only (1), but I think also fair to standardize on CMake 3.1+

[doudou]

Wouldn't be even better to use cmakes target_compile_features function to let cmake decide which compiler to use?

"target_compile_features(mylib PRIVATE cxx_std_11)"
Means the compiler has to be aware of cxx11, to me that also means, higher is also ok.

I'm OK either way. I think that the target_compile_features makes things a lot more complicated, but I guess that's the point: the C++ library maintainer is free to use whatever CMake-provided mechanism fits its use-case best. If you want to provide a C ABI with C++11 internals, then by all means use the target_compile_features mechanism. If setting the global C++ standard is good enough for your project (which is true in 99% of the cases), then use that. Just don't forget to modify the pkg-config file accordingly (the Rock macros only support the CXX_STANDARD property)

[2maz]

two statements instead of one. Is that such a great price to pay w.r.t. hiding behind layers ?

If the macro would cover only two statements, my first choice would have been clearly different. But your statement holds only if we deprecate things.

Anyhow, I am fine with deprecating rock_activate_cxx11 and using the cmake standard mechanisms.

[2maz]

Should also set CMAKE_CXX_STANDARD_REQUIRED

[doudou]

If the macro would cover only two statements, my first choice would have been clearly different. But your statement holds only if we deprecate things.

Which is what I wanted to say by "it leaves us with (1)", that is whether we want to support CMake < 3.1.

[planthaber]

As the only supported ubutnu versions are 16.04 and 18.04 and 16.04 has cmake 3.5.1 ad default, i think it is ok not to support CMake < 3.1.