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.
Add new `version=` parameter in the toolset setting to select the
version. Add variable `CMAKE_VS_PLATFORM_TOOLSET_VERSION` to hold the
version, if one is set (blank indicates default).
Fixes: #17549
While we already support `cmake --build . -- -j`, the options after `--`
are specific to the native build tool. Add new options `--parallel
[<N>]` and `-j [<N>]` to abstract this and map to the proper option
for the native build tool.
Similar to ECLIPSE_EXTRA_NATURES which can be used to add a third party
nature to the .project, this property offers the possibility to inject
third party contents into the .cproject.
An example of where this is useful is MCUXpresso. This is an IDE based
on Eclipse. Compiling through CMake generated Eclipse projects works
fine by using a custom toolchain. However, in order to be able to debug
using such a project, an extra storageModule specific to the target
board is needed in the cproject.
Create a CPack generator that uses `nuget.exe` to create packages:
https://docs.microsoft.com/en-us/nuget/what-is-nuget
NuGet packages could be easily produced from a `*.nuspec` file (running
`nuget pack` in the directory w/ the spec file). The spec filename does
not affect the result `*.nupkg` name -- only `id` and `version` elements
of the spec are used (by NuGet).
Some implementation details:
* Minimize C++ code -- use CMake script do to the job. It just let the
base class (`cmCPackGenerator`) to preinstall everything to a temp
directory, render the spec file and run `nuget pack` in it, harvesting
`*.nupkg` files...;
* Ignore package name (and use default paths) prepared by the base class
(only `CPACK_TEMPORARY_DIRECTORY` is important) -- final package
filename is a responsibility of NuGet, so after generation just scan the
temp directory for the result `*.nupkg` file(s) and update
`packageFileNames` data-member of the generator;
* The generator supports _all-in-one_ (default), _one-group-per-package_
and _one-component-per-package_ modes.
* Introduce `CMAKE_PROJECT_VERSION` and the corresponsing components:
`CMAKE_PROJECT_VERSION_MAJOR`, `CMAKE_PROJECT_VERSION_MINOR`,
`CMAKE_PROJECT_VERSION_PATCH` and `CMAKE_PROJECT_VERSION_TWEAK`.
* `CPack` module use `CMAKE_PROJECT_VERSION_MAJOR`,
`CMAKE_PROJECT_VERSION_MINOR` and `CMAKE_PROJECT_VERSION_PATCH`
to initialize corresponsing CPack variables.
This is primarily a cleanup of the cpack(1) page. The cpack.cxx file
and CPack module were also updated to make the docs relating to
the generator specification and option names consistent in all
three places.
Create `CMAKE_VS_SDK_*_DIRECTORIES` variables to tell the VS generator
how to populate fields in `.vcxproj` files that specify SDK directories.
Fixes: #17908
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 can be used for example to organize all following targets into one
Visual Studio folder:
set(CMAKE_FOLDER Libraries)
add_subdirectory(libA)
add_subdirectory(libB)
set(CMAKE_FOLDER Executables)
add_subdirectory(progA)
Another possibility is using the current directory name for all
following targets in subdirectories:
get_filename_component(dirname "${CMAKE_CURRENT_SOURCE_DIR}" NAME)
string(APPEND CMAKE_FOLDER "/${dirname}")
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>
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
This change introduces an additional property that may be set on a
target to allow additional properties to be exported. Normally only a
limited number of properties are exported.
Additional properties may be exported by simply setting the
`EXPORT_PROPERTIES` property on a target that is exported.
Since commit v3.11.0-rc1~433^2~2 (Teach target_* commands to set
INTERFACE properties of IMPORTED targets, 2017-09-18) it is now possible
to use the customary `target_*` commands for adjusting the settings of
an IMPORTED target. Update documentation accordingly.
In commit v2.8.0~170 (ENH: Added ctest test options PROCESSORS and
RUN_SERIAL, 2009-09-07) CTest learned to track the number of processors
allocated to running tests in order to balance it against the desired
level of parallelism. Extend this idea by introducing a new
`PROCESSOR_AFFINITY` test property to ask that CTest run a test
with the CPU affinity mask set. This will allow a set of tests
that are running concurrently to use disjoint CPU resources.
Document which Protocol version only needs the build directory to be passed
during a handshake.
This is available a bit earlier than that, but from all I can tell 1.2 is
the earliest version where that feature is reliably available.
The last KDevelop3 release was many years ago, in 2008 I think.
I haven't seen or read about anybody using KDevelop 3 since a
long time, so I think it can safely be removed from CMake.
KDevelop 4 (first released in 2010) has its own proper CMake
support now, independent from this generator.
Alex
Brad King