We do not add default warning flags on other compilers, and having
a warning flag in the default flags makes it hard for projects to
customize the warning level. They need to use string processing
to remove `/W3` from `CMAKE_{C,CXX}_FLAGS`. Therefore we should
drop it.
However, projects may be using string processing to replace `/W3`
with another flag, so we cannot simply drop it. Add a policy to
drop it in a compatible way.
Fixes: #18317
Replace our hard-coded defaults for `/MD` and `/MDd` with a first-class
abstraction to select the runtime library from an enumeration of logical
names. We've long hesitated to do this because the idea of "runtime
library selection" touches on related concepts on several platforms.
Avoid that scope creep by simply defining an abstraction that applies
only when targeting the MSVC ABI on Windows.
Removing the old default flags requires a policy because existing
projects may rely on string processing to edit them and choose a runtime
library under the old behavior. Add policy CMP0091 to provide
compatibility.
Fixes: #19108
The policy documentation added by commit fc8955e889 (add_subdirectory:
Run subdirectory install rules in correct order, 2018-10-02,
v3.14.0-rc1~565^2~1) left out our usual sentence about the policy
providing compatibility.
The user package registry populated by the `export()` command causes
side effects outside the build and source directories. Such effects
should be opt-in rather than op-out. Introduce a policy to change
default behavior of `export(PACKAGE)` to do nothing.
We now identify IBM's Clang-based XL compilers, which define
`__ibmxl__`, as `XLClang` rather than `XL`. In order to support
existing project code that checks for `XL`, add a policy whose OLD
behavior is to present the compiler id as `XL` and whose NEW behavior is
to present the compiler id as `XLClang` as we really detect it.
The old behavior of $<IN_LIST:...> is inconsistent with that of
if(IN_LIST), in that it does not find an empty search item even if
the list contains empty items. This change adds a new policy to
correctly handle empty items and make the behavior more consistent
with if(IN_LIST).
Fixes: #18556
Removing FindQt.cmake gives Qt upstream a path forward to export its
own QtConfig.cmake files which can be found by find_package()
without having to explicitly specify CONFIG. Projects that still
want to use Qt3/4 can call find_package(Qt[34]), include(FindQt),
or add FindQt.cmake to their CMAKE_MODULE_PATH.
* The code snippets in the docs consist of CMake code mixed
with syntax definition punctuation like < > [ ] ... Therefore
a pure CMake lexer is inadequate. Here it is replaced by a
CMake syntax definition parser.
* Fixed syntax definition snippets in FindPkgConfig.cmake to
make best use of syntax highlighting. This source file is the
hardest to support because it contains comparison operators
<= = >=, which need special attention to avoid confusion
with the placeholder indicators <...>.
* Fixed syntax in execute_process.rst (there were unbalanced
brackets).
* Disabled syntax highlighting for long string examples in
cmake-language.7.rst.
* No highlighting of removed syntax in CMP0049
* To inspect the outcome of this patch, see e.g. the pages
* manual/cmake-buildsystem.7.html
* module/ExternalProject.html
* module/FindPkgConfig.html
which are particularly rich in complex code snippets.
This was overlooked in the initial implementation of CMP0053. However,
an additional policy to reject it again is not worth it. Instead, add
tests and document the behavior.
Fixes: #17883
Before this change, install rules created by add_subdirectory()
would be executed after all of the top-level install rules, even
if they were declared before the top-level rules. This change
adds a new policy, CMP0082, which interleaves the add_subdirectory()
install rules with the other install rules so they are run in the
correct order.
This commit adds a new CMake policy, CMP0080, which prohibits the
inclusion of BundleUtilities at configure time. The old behavior is
to allow the inclusion.
Previously the command did not allow naming targets on the LHS that
were not created in the calling directory. Lift this restriction to
enable more flexible use by projects.
Targets named on the RHS will need to be looked up during generation in
the scope of the call site rather than the scope of the LHS target.
Introduce an internal syntax in `[INTERFACE_]LINK_LIBRARIES` properties
to specify target names that need to be looked up in a directory other
than that containing the target on which the property is set. Add
minimal documentation of the syntax to help users that encounter it.
Unfortunately CMake previously did allow such calls in the case that
only `INTERFACE` libraries are specified, but those libraries would be
looked up in the target's directory rather than the caller's. Add
policy `CMP0079` to enable the new behavior with new lookup scope in a
compatible way.
Fixes: #17943
Add documentation for both the CMake variable and environment variable
of this name pattern. Update references to these names to link to their
documents. Clarify the pattern used to construct their names.
Previously the command considered non-absolute source file paths relative to
the associated target on the LHS. This causes problems in incremental builds
where files are added from subdirectories and forces users to workaround by
manually converting to absolute paths. Change this to enable more intuitive
usage by projects.
Fixes#17981
Other check modules honor this variable, so include file checks should
too. Add policy `CMP0075` to enable the behavior in a compatible way.
This change was originally made by commit v3.11.0-rc1~108^2
(CheckIncludeFiles: Honor CMAKE_REQUIRED_LIBRARIES, 2017-12-24) but it
was reverted by commit v3.11.1~9^2 (Revert "CheckIncludeFiles: Honor
CMAKE_REQUIRED_LIBRARIES", 2018-04-04) because the behavior change could
affect checks in existing projects in an incompatible way.
Fixes: #9514
This feature was originally added by commit v3.9.0-rc1~71^2~2 (find_*:
Add a new PackageRoot search path group, 2017-05-03) and documented by
commit v3.9.0-rc1~71^2 (find_*: Add docs for PackageRoot search path
group, 2017-05-03). However, we had to disable the feature and remove
the documentation in commit v3.9.1~2^2 (find_*: Disable the PACKAGE_ROOT
search path group for CMake 3.9, 2017-08-08) due to breaking projects
that used `PackageName_ROOT` variables themselves.
Add policy `CMP0074` to restore the `PackageName_ROOT` variable behavior
in a compatible way. Also revise the stack of root paths to store the
paths themselves rather than the package names. This way the policy can
be considered at the `find_package` call site instead of individual
`find_` calls inside a find module.
Co-Author: Chuck Atkins <chuck.atkins@kitware.com>
Issue: #17144
Update documentation to account for commit ae5f40696e (CMP0037: Allow
test and package targets when features are not enabled, 2017-10-26).
Issue: #16062
In commit v3.5.0-rc1~8^2~2 (Help: Clarify policy `CMP0040`
documentation, 2016-01-28) the documentation was clarified to indicate
that the target must be defined in the current directory. Do the same
for the text of the policy warning itself.
Fixes: #17399
This lets AUTOMOC and AUTOUIC process GENERATED files which
used to be ignored before.
A new policy CMP0071 ensures that the old behavior of ignoring
GENERATED files is enabled when the CMake compatibility version
CMAKE_MINIMUM_REQUIRED is < 3.10.
Closes#16186
Previously `file(GENERATE)` did not define any behavior for relative
paths given to the `OUTPUT` or `INPUT` arguments. Define behavior
consistent with CMake conventions and add a policy to provide
compatibility for projects that relied on the old accidental behavior.
Fixes: #16786
Previously the `INTERPROCEDURAL_OPTIMIZATION` target property was
honored only for the Intel compiler on Linux and otherwise ignored. In
order to add support for more compilers incrementally without changing
behavior in the future, add a new policy whose NEW behavior enforces the
`INTERPROCEDURAL_OPTIMIZATION` property. Add flags for supported
compilers and otherwise produce an error.
BUILD_WITH_INSTALL_RPATH, SKIP_BUILD_RPATH, CMAKE_SKIP_RPATH and
CMAKE_SKIP_INSTALL_RPATH no longer any effect on the install name
of a target on macOS.
Fixes: #16589
Projects use `try_compile` to check if they will be able to compile some
particular source code. When a language standard variable like
`CMAKE_CXX_STANDARD` is set, then the project intends to compile source
code using a compiler mode for that standard. Therefore it makes sense
for `try_compile` to use that standard in the test project too.
Unfortunately this was not done when support for the
`CMAKE_CXX_STANDARD` variable was first implemented. Add a policy to
introduce the improved behavior in a compatible way.
Closes: #16456
In the `try_compile` source file signature we propagate the caller's
value of `CMAKE_<LANG>_FLAGS` into the test project. Extend this to
propagate `CMAKE_<LANG>_FLAGS_<CONFIG>` too instead of always using the
default value in the test project. This will be useful, for example, to
allow the MSVC runtime library to be changed (e.g. `-MDd` => `-MTd`).
However, some projects may currently depend on this not being done,
so we need to activate the behavior using a policy.
This change was originally made by commit v3.6.0-rc1~160^2 (try_compile:
Honor CMAKE_<LANG>_FLAGS_<CONFIG> changes, 2016-04-11) but without the
policy and so had to be reverted during the 3.6 release candidate cycle.
Fixes#16174.
