Feature Request: CXX_STANDARD warning/error if superseded
Context: CMake's C++ standard feature set is oriented around ensuring that a target is compiled with a minimum language standard, but AFAIK it does not provide mechanisms for ensuring that one target is compiled with the same C++ standard as another target that links against it. This is problematic for libraries where C++ standard affects API/ABI (as an example, if a polyfill type is provided for
std::optional when compiled with C++14 or earlier), which need to ensure that they are built with the same C++ standard as the targets that link against them. This problem affects the Abseil library, and there is an extended discussion about it on this GitHub issue.
absl::strings library target is built with C++14 (per
CMAKE_CXX_STANDARD value) but
my::lib is compiled with C++17 (which it inherits from
cxx_std_17 meta feature), the project will run into unhelpful linker errors. And I am not aware of any current CMake features that the Abseil library or
my::lib library could use to detect this problem and produce a clearer build error message.
With the current configuration pictured,
my::lib could add a check that fails the build if
CMAKE_CXX_STANDARD is less than 17, but if
another::lib upgraded to
cxx_std_20 in the future, this problem would happen again without a clear error message to explain the issue. So it would be much better if there were a CMake mechanism to enforce the build's semantic constraints around C++ standard.
Feature Request: Open to other solutions to the above problem, but I believe one approach that could work would be:
- Allow detection of situation where a target's
CXX_STANDARDproperty (usually initialized by
CMAKE_CXX_STANDARD) is superseded by an inherited C++ feature requirement (such as the
- This could be configured as a target-level property (above, for
my::lib) or as a policy for a whole CMake project.
- Allow projects to chose whether this would result in a build warning or fatal error.
Would love some feedback from CMake contributors about the right design here. If we can reach consensus, I'm also happy to contribute the implementation (ideally along with a few code pointers as to where to implement + how to test). Thanks very much!