OK, sounds like an environmental regression then. We are in the process of updating our CI to Fedora 34 which includes GCC 11, so this might show up there.
This is working as designed. The cxx_std_17 feature is documented here. It does not mean “pass -std=c++17”. It means “run the compiler in a mode that supports C++17”. If the default compiler mode supports C++17, no flag is added.
gcc 11 defaults to C++17, and so does not need any -std= flag to satisfy cxx_std_17. On Fedora 34:
Thank you very much for your help!
The problem was that a fetched and build dependency sets the global standard to set(CMAKE_CXX_STANDARD 11).
But I think it is quite cumbersome that even though I require a target to be built with c++17 it is not. Is there another option then setting it globally?
I came accross this today as well. It’s quite annoying because some of the lint (e.g. clangd) rely on compiler_commands.json for the settings. They don’t know gcc version and hence cannot infer --std
See my above reply. The behavior of cxx_std_## not always adding -std= is now also documented here. If you want explicit -std= options to appear in compile_commands.json, you need to set CMAKE_CXX_STANDARD to the desired standard level. That setting uses the given standard unless a cxx_std_## feature needs a higher one, and therefore should always pass a -std= flag.
I am working with CMake 3.22.1, emacs IDE and clangd 12 as static analyzer. I have an interface library with a set of tests, and even if I set CXX_STANDARD 17 either for my library or for my tests, I don’t get the -std=… option in the compile_commands.json. I also tried setting CMAKE_CXX_STANDARD, but that doesn’t work either. Am I missing something?
Oops thanks for the remark!
I managed to force the flag though, by adding the CXX_STANDARD_REQUIRED ON property along with the CXX_STANDARD one.
Thanks for you help.