Fixes #15592

Introduce CMake policy `CMP0096` to make `project()` keep leading zeros
in version components.  As a side effect, it now allows really long
version numbers.

Fixes: #19421
Co-Author: Brad King <brad.king@kitware.com>

CMP0095 was introduced in 3.16, but was mistakenly put in the notes
for 3.15. This error was not caught during review. Move it into the
notes for 3.16.

Escape coincidental CMake syntax in RPATH entries when generating the
intermediary cmake_install.cmake script.

Fixes #19225

This aligns module mode behaviour with config mode.

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 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.

This also introduces CMP0087 which will keep the OLD behaviour of not
evaluating generator expressions

Fixes: #15785

When file property SWIG_MODULE_NAME is specified, provide option -module
to SWIG compiler.

Fixes: #18374

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.

Fixes: #14983, #16561

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 policy CMP0077 to change this behavior in a compatible way.

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

Introduce policy `CMP0073` to avoid producing these cache entries.

Fixes: #16364

Fixes: #17449

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.

In Sphinx output formats that print the toctree the policy numbers in
links from the cmake-policies(7) manual are not descriptive.  Convert
the toctree entries to cross-reference syntax and add the summary of
each policy.  For now simply duplicate the policy summary line.  We
already maintain copies in `cmPolicies.h` and `Help/policy/*.rst` docs.

This new policy restricts the addition of the shared library link flags
to executables only when the ENABLE_EXPORTS property is set to True.

if(TEST TestNameThatExists) will return true if a test with the name
TestNameThatExists has been added with add_test.  The syntax is similar
to if(TARGET TargetName).  Since use of "TEST" as an argument to if()
could previously be interpreted as a non-keyword argument, add policy
CMP0064 to treat it as a keyword as NEW behavior.

The most likely documentation page a project author will read in
response to a policy warning is the page for the policy itself.
Add to every policy documentation page a note explicitly stating
that the OLD behavior is deprecated.  Also mention this in the
cmake_policy() command documentation that explains how to set a
policy to OLD.
Suggested-by: Fraser Hutchison <fraser.hutchison@gmail.com>

The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN were first
merged in commit v2.8.12~322 (Merge topic 'VISIBILITY_PRESET-property',
2013-06-05) but worked only for shared libraries and executables with
exports.  Prior to commit v3.0.0-rc1~581^2 (GenerateExportHeader:
Deprecate add_compiler_export_flags function., 2013-09-02) the
add_compiler_export_flags function was used to add visibility flags to
all targets.

The visibility flags are useful for sources in all target types because
they may be later linked into shared libraries or executables with
exports.  Introduce policy CMP0063 to enable them for all target types
while preserving compatibility with existing projects that do not expect
this.