This extends the descriptions of command signatures and options.
Additional examples are listed at the bottom for better understanding
and overview of this command.
381c446ff7 VS: Remove support for appending a platform to the generator name
dc24d88062 Remove compatibility with CMake versions older than 3.1
90d814f024 CMP0054: Remove support for OLD behavior
292aaffb78 Source: Remove unused cmCommandArgument{Lexer,Parser}
1150fae89a CMP0053: Remove support for OLD behavior
f0b1ca4d70 CMP0052: Remove support for OLD behavior
e4fddc8e37 CMP0051: Remove support for OLD behavior
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10205
This compatibility has been deprecated since commit 3a4791548d
(Deprecate compatibility with CMake versions older than 3.5, 2023-02-09,
v3.27.0-rc1~508^2). The behavior itself has been deprecated
since CMake 3.1.
Issue: #26613
This compatibility has been deprecated since commit 3a4791548d
(Deprecate compatibility with CMake versions older than 3.5, 2023-02-09,
v3.27.0-rc1~508^2). The behavior itself has been deprecated
since CMake 3.0.
Issue: #26613
This compatibility has been deprecated since commit 5845c218d7
(Deprecate compatibility with CMake versions older than 2.8.12,
2020-06-12, v3.19.0-rc1~629^2). The behavior itself has been
deprecated since CMake 2.8.12.
Issue: #26613
This compatibility has been deprecated since commit 5845c218d7
(Deprecate compatibility with CMake versions older than 2.8.12,
2020-06-12, v3.19.0-rc1~629^2). The behavior itself has been
deprecated since CMake 2.8.0.
Issue: #26613
b010a1fb1d Help: Update try_compile list of automatic policies
5e9b40b6a5 Help: Update cmake-buildsystem(7) TARGET_POLICY example to a newer policy
9ffbc0e628 Tests/RunCMake/cmake_minimum_required: Generalize deprecated version case name
0eca249ac7 Tests/RunCMake: Update more cmake_minimum_required versions to 3.10
a8cf033a74 Tests/RunCMake/return: Use newer cmake_minimum_required VERSION
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !10178
Re-organize the "Binary Targets" section of the manual to have a
dedicated subsection for each kind of binary target. Initialize each
subsection by documenting the object file and link semantics of the
corresponding target type.
Update find_package documentation to describe (the current state of)
support for Common Package Specification packages. Make some general
improvements to the same while we're at it. Add documentation blurb for
the experimental flag that enables CPS support.
Teach find_package to search CPS search paths, and to look for CPS file
names. Modify the set of file names to also include the file type (CPS
or CMake-script). Modify the search function to allow specifying which
file type(s) to consider.
During full path search, each possible path is searched for only one of
the two possible file types. However, subsequent runs, or when
considering a user-specified path (<name>_DIR), CMake will look for both
file types.
Note that this only adds the new path search logic as described above;
CMake does not yet know how to read CPS files, and there is a high
likelihood that Bad Things will happen if it tries. However, this seemed
like a good place to checkpoint.
Add cmAnyDirectoryListGenerator, which matches any directory but also
sorts matches in the same manner as cmProjectDirectoryListGenerator.
Modify SearchFrameworkPrefix to use this, in combination with a literal
path (cmAppendPathSegmentGenerator), instead of cmFileListGeneratorGlob
(which is removed, as it is no longer used). This improves the
consistency of when sorting is available.
This uses cmDirectoryListGenerator's new ability to match anything, as
mentioned in the previous commit.
The `BUILD_TESTING` variable is referenced in `add_test` and
`enable_testing`. It should be documented as it controls the
behavior tests working when projects use `include(CTest)`.
Add documentation to clarify that `find_package` searches paths in the
specified order and stops at the first match. Clarify documentation of
`CMAKE_FIND_PACKAGE_SORT_*` to match the actual behavior.
Note that no behavior is actually changed, this merely improves the
documentation to reflect actual behavior rather than seeming to imply
something else.
Also, update the test to verify that what we claim in the updated
documentation is what's actually happening.
Re-introduce the behavior originally introduced in CMake 3.30.3 by
commit c1ece78d11 (project: non cache <project> prefix variables are
also created, 2024-08-27, v3.30.3~2^2), but this time with a policy for
compatibility.
Issue: #25714
Issue: #26243
The change in commit 86ad7cc886 (project: Only define non-cache vars if
already defined, 2024-09-15, v3.30.4~2^2) was meant to only check for
non-cache variables when deciding whether to set non-cache project
variables for the current call. However, it erroneously checked for any
variable, including cache variables. This gives the intended result on
the first run, but on subsequent runs a cache variable will exist that
did not on the first run, leading to different behavior between the two
runs. Fix the logic to only check for a pre-existing non-cache
variable, as was originally intended.
Fixes: #26355
Issue a deprecation warning on calls to `cmake_minimum_required` or
`cmake_policy` that set policies based on versions older than 3.10.
Note that the effective policy version includes `...<max>` treatment.
Update the check from commit 3a4791548d (Deprecate compatibility with
CMake versions older than 3.5, 2023-02-09, v3.27.0-rc1~508^2).
