Simplyfy c++ version check

[autoantwort]

This has the same effect then the code before.

[maloel]

Hi @autoantwort

Thanks!

May I ask what prompted you to make this change, though? Did it not work?

The CMAKE_CXX_STANDARD no longer being there and therefore perhaps going awry in the other projects. Also, what happens when another project specifies cxx_std_17, for example? Will the latest (17) be used, or both? Before, we left the client to its own devices but here we're setting 11...

[autoantwort]

The motivation was that I currently get:

CMake Error at CMake/lrs_macros.cmake:17 (message):
  Project 'realsense2' requires C++14 or higher
Call Stack (most recent call first):
  CMakeLists.txt:53 (config_cxx_flags)

but I use the most recent apple clang version ... The underlying problem is probably

Performing C++ SOURCE FILE Test SUPPORTS_CXX14 failed with the following output:
Change Dir: /Users/leanderSchulten/git_projekte/vcpkg/buildtrees/realsense2/arm64-osx-rel/CMakeFiles/CMakeScratch/TryCompile-gF8fd4

Run Build Command(s):/Users/leanderSchulten/git_projekte/vcpkg/downloads/tools/ninja/1.10.2-osx/ninja cmTC_6bf46 && [1/2] Building CXX object CMakeFiles/cmTC_6bf46.dir/src.cxx.o
clang: warning: -latomic: 'linker' input unused [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-mfpu=neon' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-mfloat-abi=hard' [-Wunused-command-line-argument]
[2/2] Linking CXX executable cmTC_6bf46
FAILED: cmTC_6bf46 
: && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -fPIC -pedantic -g -Wno-missing-field-initializers -Wno-switch -Wno-multichar -Wsequence-point -Wformat -Wformat-security -mfpu=neon -mfloat-abi=hard -ftree-vectorize -latomic -pthread  -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/cmTC_6bf46.dir/src.cxx.o -o cmTC_6bf46   && :
ld: library not found for -latomic
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

But why do a try_compile if cmake can do it natively.

[autoantwort]

Also, what happens when another project specifies cxx_std_17, for example? Will the latest (17) be used, or both?

target_compile_features specifies the minimum required c++ version needed to compile the project.

target_compile_features(main PRIVATE cxx_std_14)
target_compile_features(main PRIVATE cxx_std_11) # it is still 14
target_compile_features(main PRIVATE cxx_std_17) # now it is 17

set(CMAKE_CXX_STANDARD 17)
add_library(main main.cpp)
target_compile_features(main PRIVATE cxx_std_14) # now compiled with C++17 because of CMAKE_CXX_STANDARD

set(CMAKE_CXX_STANDARD 11)
add_library(main main.cpp)
target_compile_features(main PRIVATE cxx_std_14) # compiled with C++14

Before, we left the client to its own devices but here we're setting 11...

But the clients must at least choose C++11 right? Now C++11 is used when nothing is specified and if they specify something this is used (C++11 is used if they specify something smaller than c++11)

[maloel]

I use the most recent apple clang version ...

I think, as of clang 16, c++17 is the minimum so specifying c++14 probably generates your error. This is a problem, I agree. You don't have a problem with -std=c++11, e.g. when compiling rsutils?

It's funny, because of all the builds in our CI it was the Mac build that failed...

All the rest of your comments make sense, but we need to be careful here. Let's see what the CI says...

[autoantwort]

You don't have a problem with -std=c++11, e.g. when compiling rsutils?

No. Ci also seems to be happy.

Now only LRS_libci_trigger is failing, but I don't know why.

[Nir-Az]

@maloel any inputs regarding this PR?

[maloel]

Looks like newer code in rsutils requires C++14. Testing offline...