25f29b9741 cuda: Adapted tests to work with modified cuda toolset
ee86770a3f cuda: Added docs for extended cuda toolset
0ad180d712 cuda: Extend cuda compiler detection to work with custom cuda path
55b0532128 cuda: Extend vs10 target generator to use custom cuda path
df0247a371 cuda: Extend toolset argument to accept path
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3713
For the multi-configuration generators one can specify the list
of configurations to include in the package.
E.g. having a project, where debug libraries have a suffix to
distinct them from the release builds, one can build the package
containing both `Debug` and `Release` binaries.
Extend the change from commit 689be6235e (Generator: support
per-language link library flag, 2019-08-08) to cover more link library
command-line flag components. Allow compilers for different languages
to use different values for these linking-related variables within the
same build.
Closes: #19631
Swift has supported `CMAKE_Swift_LANGUAGE_VERSION` and
`Swift_LANGUAGE_VERSION` but didn't apply that to Ninja generated
targets. Consider the property when calculating the flags.
Update command-line options, script variables, and documentation to use
the term "group" instead of "track". The old terms are still available
for now, but they are now undocumented.
This makes our terminology more consistent with CDash. The goal of this
change is to make it more clear to our users how CTest and CDash interact
with each other.
This enables the use of MSVC and Swift on Windows in a single project.
MSVC uses no flag to indicate linked libraries while Swift uses `-l`.
Add support for a language specific link library flag which takes
precedence over the global `CMAKE_LINK_LIBRARY_FLAG` which preserves
compatibility with earlier releases.
The NDK build system now uses only a single toolchain in
<ndk>/toolchains/llvm/prebuilt/<host>
Its compilers are always `bin/{clang,clang++}` and its binutils are
always `bin/<triple>-*`. It is a standalone toolchain:
* The Anrdoid API level is specified at the end of `--target=`.
* The standard library may be specified via `-stdlib=`.
* No need to pass system includes or libraries explicitly.
* No need to pass `--sysroot` or `-gcc-toolchain`.
Teach CMake to recognize NDK versions that have a unified
toolchain with its own sysroot and use the above approach.
Fixes: #18739
The singular name `CPACK_INSTALL_SCRIPT` has existed but was not linked
from the CPack documentation. Also, it supported multiple values and
should have had a plural name. Add a plural-named alternative now.
If both `CPACK_INSTALL_SCRIPTS` and `CPACK_INSTALL_SCRIPT` are set then
ignore the latter with a warning.
Signed-off-by: Alex Turbov <i.zaufi@gmail.com>
0ba5891ead project: Keep leading `0` in PROJECT_VERSION components
5f84669806 Tests: Factor out RunCMake.project helper macro into module
b1f387a7ea Refactor: Use raw string literals instead of escaping
41b85968d8 Refactor: Use initializer lists instead of `push_back` series
45e85dd2b2 Refactor: Add some `const` to vars
90f91e4d21 Refactor: Replace a "magic" number w/ a named constant
638383c38f Refactor: Eliminate one-time-used variables
9b6a53292f Refactor: Eliminate `sep` from the loop
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3517
On AIX, plugins meant to be loaded into executables via `dlopen` must be
linked with access to a list of symbols exported from the executable in
order to use them (when not using runtime linking). The AIX linker
supports specifying this list as an "import file" passed on the command
line either via the `-bI:...` option or (with a leading `#! .` line) as
a normal input file like any other library file.
The linker import file plays the same role on AIX as import libraries do
on Windows. Teach CMake to enable its import library abstraction on AIX
for executables with the `ENABLE_EXPORTS` target property set. Teach
our internal `ExportImportList` script to optionally generate a leading
`#! .` line at the top of the generated export/import list. Update our
rule for linking an executable with exports to generate a public-facing
"import library" implemented as an AIX linker import file.
With this approach, our existing infrastructure for handling import
libraries on Windows will now work for AIX linker import files too:
* Plugins that link to their executable's symbols will be automatically
linked using the import file on the command line.
* The executable's import file will be (optionally) installed and
exported for use in linking externally-built plugins.
This will allow executables and their plugins to build even if we later
turn off runtime linking.
Issue: #19163
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>
CMake's find control flags should all have a consistent name.
To make this happen we are introducing `CMAKE_FIND_USE_REGISTRY`
and deprecating `CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY`.
The message() command requires uppercase log levels. Even
though the cmake --loglevel option is not case sensitive, show
the supported values as uppercase to match the message()
docs as closely as possible, since they are related to the same
feature.
Also fixes the wrong string being shown for the warning level
by cmake --help.
d5b722bbbd Help: Remove mention of CMAKE_INSTALL_DO_STRIP
ddc7ea4696 Help: Clarify how to provide multiple targets with cmake --target
c509f38b7b Help: Add missing xref for CMAKE_EXECUTE_PROCESS_COMMAND_ECHO
9cc6befe1b Help: Improve formatting of list(TRANSFORM) sub-options
074fbdb73f Help: Clean up trivial typos and grammar
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Brad King <brad.king@kitware.com>
Merge-request: !3498
It isn't yet clear whether we want to make this part of the
documented API for the install script. Remove it from the
docs before it appears in an official release for now.
Relates: #18997
