Add an argument to the `project` command to allow specifying a license
for a project as a whole. This is in addition to specifying licenses on
individual targets, and will be used to set the license(s) on exported
packages.
Also, move listing of `COMPAT_VERSION` variables to follow
lexicographical order.
Since commit 84db8506ff (Deprecate compatibility with CMake versions older
than 3.10, 2024-10-03, v3.31.0-rc1~23^2) the `cmake_minimum_required` and
`cmake_policy` commands warn if the project does not enable policies as
of 3.10 or higher. Clarify the advice given in the warning message about
how to update the version specification, particularly without actually
requiring a newer minimum version of CMake.
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).
In c1ece78d11 (project: non cache <project> prefix variables are
also created, 2024-08-27), we started explicitly setting the non-cache
variable for <projectName>_SOURCE_DIR, <projectName>_BINARY_DIR,
and <projectName>_IS_TOP_LEVEL in addition to setting them as
cache variables. This changed the behavior when a project name
was used more than once, and the second project call happens in
the same scope or a child scope of the first. Previously, the first
project call would set cache variables, and the second project call
would not overwrite those cache variables. With the change in
c1ece78d11, after the second project call the non-cache variables
would mask the cache variables and the project code would see
a different value to what it did before.
Setting the non-cache variable was added to handle the case where
a call to FetchContent_MakeAvailable() would set some non-cache
variables, and it just so happened those matched the same cache
variables that the project() command would set in the project being
fetched. The fetched project would then see a different set of
project-specific variables compared to when it was built standalone.
This commit here narrows the change from c1ece78d11 such that
the non-cache variable is only set by project() if there was already
a non-cache variable set. This still fixes the motivating problem
c1ece78d11 was intended to solve, but it avoids changing the variable
values seen by a project that re-uses the same project name in related scopes.
Issue: #26243, #25714Fixes: #26281
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.
