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
Previously, `install(TARGETS)` would only accept targets created in the same
directory scope. Relax this restriction by searching the global scope when
determining whether or not a target exists.
Fixes: #14444
66ea1a3795 LINK_OPTIONS: Add support of "LINKER:" prefix
c1f5a44b28 LINK_OPTIONS: Add new family of properties
8e28d2630a Makefile generator: link flags management refactoring
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alex Turbov <i.zaufi@gmail.com>
Merge-request: !2033
This family enable to manage link flags
Three new properties:
* directory property: LINK_OPTIONS
* target properties: LINK_OPTIONS and INTERFACE_LINK_OPTIONS
Two new commands
* add_link_options(): to populate directory property
* target_link_options(): to populate target properties
Fixes: #16543
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.
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.
Fixes: #17943
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.
7e8046e20b Help: add release notes for NAMELINK_COMPONENT
c02eeb0853 Help: clarify "undefined behavior" in install(EXPORT) command
edcb545a24 install: add test for new NAMELINK_COMPONENT parameter
0212d7c762 install: add NAMELINK_COMPONENT argument
cbb609072f Help: clean up install(TARGETS) documentation
b81280ba1f Help: add list of command signatures to top of INSTALL page
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alex Turbov <i.zaufi@gmail.com>
Merge-request: !1982
* 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.
An effect of the `-isystem` flag is to search the directory after those
specified via `-I` flags. Make behavior more consistent on compilers
that do not have any `-isystem` flag by explicitly moving system include
directories to the end.
b1f95e5b14 Fortran: Extend submodule test with great-grandchild
402735314e Fortran: Add support for submodule dependencies
62538b2c4c Fortran: Refactor to treat .mod extension as part of module name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Izaak Beekman <contact@izaakbeekman.com>
Merge-request: !1989
a4f71b4ba8 Help: Document existence of cmake_install.cmake
fcf64866da Help: move DESTDIR into a separate page
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1979
Since commit v3.7.0-rc1~73^2~1 (Fortran: Add support for submodule
syntax in dependency scanning, 2016-09-05) we support parsing Fortran
sources that use submodule syntax, but it left addition of `.smod`
dependencies to future work. Add it now.
The syntax
submodule (module_name) submodule_name
means the current source requires `module_name.mod` and provides
`module_name@submodule_name.smod`. The syntax
submodule (module_name:submodule_name) nested_submodule_name
means the current source requires `module_name@submodule_name.smod`
provides `module_name@nested_submodule_name.smod`.
Fixes: #17017
