Skip to content

cmStandardLevelResolver: Use flag if extensions don't match compiler's default, don't add flag if not necessary

Raul Tambre requested to merge tambre/cmake:default_extensions into master
  • Renamed language_dialect to language_standard to better reflect its meaning.
  • Add detection of whether compiler extensions are enabled by default or not.
  • Fix compiler extensions not being turned off when no standard level was requested.
  • Avoid adding standard level flags if not necessary (i.e. matches the compiler's defaults).


  • Add a policy for "Standard flags are no longer added if mode matches desired". This breaks existing code when:

    • LANGFLAGS=<flag for standard newer than CMAKE_LANG_STANDARD_DEFAULT>
    • Project relies on LANG_STANDARD being the standard.

    Previously we'd always add the flag if LANG_EXTENSIONS=ON, but we no longer do. In such cases the project should set LANG_STANDARD_REQUIRED=ON to make sure it gets the exact mode it specified.

  • Add tests for LANG_STANDARD_REQUIRED=ON really passing the flag. Need to select a combination which the compiler's default mode doesn't match. Should help catch this mistake.

    Resolution: This is mostly already covered, the referenced typo would be caught by the tests for the next case.

  • Add tests for LANG_STANDARD is unset and LANG_EXTENSIONS!=CMAKE_LANG_EXTENSIONS_DEFAULT that the correct flag is passed. I.e. a test case for #22224 (closed).

  • Figure out why BootstrapTest is failing on Solaris. For some reason std::unique_ptr isn't available without any flags. Incorrect default standard detection?

    Resolution: Removed incorrect check for ext != defaultExt. It wasn't actually necessary and would result in us trying to use non-existant flags in cases where LANG_STANDARD!=CMAKE_LANG_STANDARD_DEFAULT and LANG_EXTENSIONS!=CMAKE_LANG_EXTENSIONS_DEFAULT.

  • Figure out CrayPE GTK2 failures. Expecting a brace likely due to the __attribute__((__deprecated__("whatever"))). Needs GNU mode, default wrongly detected?

    Resolution: Magically went away, might've been caused by something else.

  • Add references/updates to the policy to the relevant generic language/extension pages.

    • cmake-compile-features(7)'s "Availability of Compiler Extensions"
  • Add warnings for the policy.

  • Add tests for the warnings. Requires introspection.

  • Update release notes to refer to the policy.

  • Figure out the reasons for nightly failures with the policy set to NEW.

Improved introspection from generate_feature_list in this MR should help with adding the additional tests depending on the environment.

Edited by Raul Tambre

Merge request reports