Issue a deprecation warning on calls to `cmake_minimum_required` or
`cmake_policy` that set policies based on versions older than 3.5.
Note that the effective policy version includes `...<max>` treatment.
Update the check from commit 5845c218d7 (Deprecate compatibility with
CMake versions older than 2.8.12, 2020-06-12, v3.19.0-rc1~629^2).
For policy-specific tests, use the version before the policy was
introduced. Otherwise, use 3.5 where possible.
Also, remove `cmake_minimum_required()` and `project()` calls from
individual cases where they are handled by `CMakeLists.txt`.
cmMakefile::EnableLanguage() now deduplicates the languages argument and
emits an author warning listing the languages that were defined multiple
times in a single call.
Fixes: #23596
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.16 and below to encourage projects to port
away from setting policies to OLD.
Define `PROJECT_IS_TOP_LEVEL` and `<PROJECT-NAME>_IS_TOP_LEVEL`. The
latter is a STATIC cache entry just like other `<PROJECT-NAME>_*`
variables so that it is globally scoped.
Issue: #20310Fixes: #21961
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>
This sets variables like PROJECT_HOMEPAGE_URL, which can be
used as default values for various things (packaging modules,
doxygen defaults, etc.). Some packaging modules have been
updated to do this as part of this commit.
Co-Author: Craig Scott <craig.scott@crascit.com>
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for some policies
to encourage projects to port away from setting policies to OLD.
It is quite often the project description has used in a real world software.
Examples include:
* part of a help screen of the application
* builtin resources (`*.rc` files, data for "About" dialog of a GUI app, & etc)
* most generators for CPack can use it
* it could be used by documentary software (Doxygen, Sphinx) which is usually
integrated to CMake based projects via `add_custom_target()`
Now `project()` call learned an optional `DESCRIPTION` parameter with a
short string describing a project. Being specified, it would set the
`PROJECT_DESCRIPTION` variable which could be used in `configure_file()`
or whatever user wants. Also `PROJECT_DESCRIPTION` is a default value
for `CPACK_PACKAGE_DESCRIPTION_SUMMARY`.
The check added in commit v3.6.0-rc1~293^2 (Diagnose recursive
project/enable_language without crashing, 2016-03-07) broke support for
enabling `RC` explicitly along with other languages like `C`. The
reason is that we enable all listed languages at once so the internal
`enable_language(RC)` that we do while enabling `C` or `CXX` on some
platforms triggers the recursion check if `RC` is explicitly listed.
Ideally we should refactor things to only enable one language at a time,
but for now it is simplest to just exclude `RC` from the explicit list
until other languages are enabled, and then enable it.
Closes: #16330
Teach the project() command to set variables
{PROJECT,<PROJECT-NAME>}_VERSION{,_MAJOR,_MINOR,_PATCH,_TWEAK}
holding the project version number and its components. Add project()
command option "VERSION" to specify the version explicitly, and default
to the empty string when it is not given.
Since this clears variables when no VERSION is given, this may change
behavior for existing projects that set the version variables themselves
prior to calling project(). Add policy CMP0048 for compatibility.
Suggested-by: Alex Neundorf <neundorf@kde.org>
Teach the project() command to recognize an optional "LANGUAGES"
keyword after the project name and prior to the list of languages.
Do not allow multiple copies of the keyword. If the keyword is
specified and no languages are listed, imply NONE.
