I think the topic title is self-explanatory.
So far, it seems that set_target_properties(${TARGET_NAME} PROPERTIES CXX_EXTENSIONS OFF) does nothing more than using -std=c++xx instead of -std=gnu++xx.
For gcc I must add -pedantic-errors, for clang it seems that you must add an error flag per extension, these I don’t have the list of. Fr msvc /permissive- seems enough.
Regards
nobody?
Unclear what the question is or what answer is being sought.
You’re correct that turning off extensions determines the standard mode passed to the compiler. You’re also correct that many compilers will enable some extensions anyway (usually extensions which do not conflict with and have no meaning in the ISO standard). Some extensions are mutually exclusive with ISO-standard C++ and these are the ones which are generally controlled by the standard mode.
You’re further correct that using -pedantic-errors with GCC/Clang will force the compiler to error out on ISO-diagnostic required code.
The purpose of CXX_EXTENSIONS is to control the language standard passed to the compiler, not force errors. Some programs will only compile under ISO dialect, and some will only compile under GNU dialect (or another C++ dialect). If your program has such a restriction, you should use CXX_EXTENSIONS to communicate that requirement. If you program compiles under either dialect, you should not use the property.
If you simply want to use certain warning flags as a testing and correctness mechanism in CI or development builds, you should communicate that via CMAKE_CXX_FLAGS or a CMake presets.
I would have to disagree, unless I’m misunderstanding your wording. A project may want to enforce that it is not allowed to use extensions, so it will set CXX_EXTENSIONS to false. It’s not saying it can’t be compiled with extensions enabled, it’s about the constraint that it wants to enforce (this might be a certification requirement, for example). This is very common, I see it with almost all my consulting clients.
CXX_EXTENSIONS is insufficient to enforce such a check. You want -pedantic-errors or equivalent. The CXX_EXTENSIONS selects only which dialect of C++ you get.
Selecting which dialect of a language a project is built under, like selecting the version, or the compiler, is best left to the invocation of CMake. You shouldn’t hardcode it for the same reason you wouldn’t hardcode CMAKE_CXX_COMPILER, CMAKE_CXX_STANDARD, or CMAKE_CXX_FLAGS. You leave that to the user building the project to decide.
If the author of the project is the only person who will ever build the project (it is never packaged by others), the point is moot. All working solutions are equal if the only consumer of the project description is the author.
thanks to both of you.
I’ll try to clarify: by setting CXX_EXTENSIONS to off, my expectation is to disabling all extension. Period. Meaning that, if my could is legal with some extension but not in iso C++, I must have a hard error, possibly with a message explaining that it would be valid with such or such extension.
As I said, it seems tractable with gcc and msvc (for now) but not for clang that requires to disable explicitly each extension separately (through a warning set to error).
I would have expected from CMake to set automatically the appropriate warning flags (also -pendantics-errors for gcc, /permissive- for msvc) when CXX_EXTENSIONS is off, and maintain the behavior with respect to the compiler and its version.
I hope it’s clearer
CMake does not have an abstraction for this semantic. Right now you need to set flags by one mechanism or another. You have already reached that answer yourself, so you’re not missing anything.
This is a valid feature request, you can open an issue describing the use case. Something like CMAKE_<LANG>_PEDANTIC or CMAKE_<LANG>_STRICT.
Understood Mr. Gamberini, done