Fixes#17559
Replace our hard-coded default of cudart=static with a first-class abstraction to select the runtime library from an enumeration of logical names.
QCC is a wrapper around GCC, but it is not a fully transparent wrapper.
Some compile options need to be passed to GCC using a `-Wc` option.
QCC does not support --sysroot, so setting CMAKE_SYSROOT in a toolchain
file currently does not work. This means that it is likely that no one
is setting CMAKE_SYSROOT in existing QNC toolchain files. Override the
GCC option for sysroot in the QCC.cmake file with -Wc,-isysroot.
This exposes a further issue in that the QNX SDK does not follow the
same architectural folder structure as linux uses. That is, on linux
systems, architecture-specific libraries might be in
<sysroot>/usr/lib/<arch>
such as
/usr/lib/x86_64-linux-gnu/libcurl.so
CMake models this by suffixing the <arch> onto lib directories when
searching for libraries.
The QNX SDK is structured differently such that the <arch> should be
used as a prefix:
<sysroot>/<arch>/usr/lib
such as
<sysroot>/x86_64/usr/lib/libcurl.so
Add a variable for platform configuration to set whether to prefix or
suffix the <arch> and set that in the QCC.cmake.
Use the directory structure of the QNX SDK to compute the <arch> from
the implicit library directories. The assumption is that the arch will
be a single directory directly below the CMAKE_SYSROOT, below which the
usr/ prefix occurs.
It would not be appropriate to instruct users to make the <arch> part of
the sysroot when specified in the toolchain file because:
1. That would be non-DRY - The QCC wrapper already determines the <arch>
by the -V argument passed to the compiler, specified in the toolchain
file as the CMAKE_C_COMPILER_TARGET variable.
2. The includes in the QNX SDK are not below the <arch> directory.
So, the location of the <arch> in the full path is different on QNX
compared to, say an embedded linux platform, but the intent is the same.
Add documentation to recommend the use of CMAKE_SYSROOT in a QNX
toolchain file.
As the CMAKE_SYSROOT is always the same for QNX, it would be possible to
simply set it in QCC.cmake. However, that would change behavior for
existing users as when CMAKE_SYSROOT is set, files/paths outside of the
CMAKE_SYSROOT do not get found.
The <arch> prefixing is only enabled in cmSearchPath.cxx if
CMAKE_SYSROOT is set. This ensures that the user gets consistency in
the current state without CMAKE_SYSROOT, and gets better consistency
when using CMAKE_SYSROOT.
b7a2baf38c Ninja Multi-Config: Add variable to control configs used in cross-config build
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4269
Add the timestamp and stack depth of the function call to the JSON trace
output format. This information can be useful for cmake profiling and
call stack inspection (see e.g. https://github.com/volo-zyko/cmake-profile-stats).
Improve unit test to allow for varying set of keys to check in trace lines.
3ec82b713e cmMarkAsAdvancedCommand: ignore variables which don't exist in the cache
701a5c60e0 cmake: avoid marking local or unused variables as advanced
af158149e7 FindOpenSSL: do not mark a local variable as advanced
74f659f1f2 FindCurses: only mark CURSES_EXTRA_LIBRARY when it is used
7e2ae4e96d FindOpenGL: only mark declared cache variables as advanced
7cc02a0c29 FindLua: only mark LUA_MATH_LIBRARY as advanced if required
85cd26b8a6 FindBoost: only mark Boost_DIR as advanced if defined
338c7916ba CTest: avoid marking undeclared cache variables as advanced
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4150
Modern distributions of packages built with MinGW tools provide `.dll.a`
import libraries. Prefer those instead of finding plain `.dll` files.
This avoids accidentally finding unrelated Windows `.dll` files.
Fixes: #20019
f0e67da061 target_link_libraries: Fix out-of-dir linking of a list of targets
acee629103 cmTargetLinkLibrariesCommand: Move HandleLibrary to helper struct
ba675f1ecc Tests: Enable CMP0022 in ExportImport out-of-dir linking case
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4226
In a case like
target_link_libraries(targetInOtherDir PUBLIC "$<1:a;b>")
then all entries in the list need to be looked up in the caller's
scope. Previously our `::@(directory-id)` suffix would apply only
to the last entry. Instead surround the entire entry by a pair
`::@(directory-id);...;::@` so that the `::@` syntax can encode
a directory lookup scope change evaluated as the list is processed.
Fixes: #20204
Add a `JOB_POOL_PRECOMPILE_HEADER` target property to specify the pool
name, and its associated `CMAKE_JOB_POOL_PRECOMPILE_HEADER` variable.
Fixes: #20217
The `FPHSA_NAME_MISMATCHED` variable may be set if this is intentional
(but should be cleared after the call to not affect other FPHSA calls).
It may also be passed via the `NAME_MISMATCHED` option for new-signature
FPHSA calls.
The `-Wmost` flag was added by commit 97a51d2172 (ENH: add more xcode
stuff, 2005-01-27, v2.4.0~2396), along with a couple others, as part of
very early work on the Xcode generator. I suspect that the flags were
part of Xcode's project creation wizard. However, they are not
appropriate for CMake-based projects because we already have our own
mechanisms for specifying flags desired by the project or user.
Simply drop the flags.
Fixes: #13516
Add some prose to the documentation index page to guide readers to the
major manuals and guides.
Add a new "User Interaction Guide" to help the class of new user
who wishes to build a project with CMake for the first time, such as
after cloning a repo from a git repository.
Add a new "Using Dependencies Guide" to help the class of new
user who wishes to consume a SDK provided by a third party and needs a
starting point. This is a different type of user to the user who wishes
to create their own project from scratch (addressed by the
`cmake-buildsystem(7)` manual) as each will encounter needs for
information discovery in a different order.
Many users will want to use the Ninja Multi-Config generator like a
traditional Visual Studio-style multi-config generator, which doesn't
mix configurations - custom commands are built using target executables
of the same configuration the command is for. We do not want to force
these people to generate an N*N build matrix when they only need N*1,
especially if they have lots of targets. Add a new variable,
CMAKE_NINJA_CROSS_CONFIG_ENABLE, to opt-in to the cross-config build
matrix.
In commit a1ad0a699b (target_link_libraries: Allow use with targets in
other directories, 2018-09-07, v3.13.0-rc1~94^2) we added use of `<...>`
to encode a directory id, but the closing `>` can incorrectly terminate
a surrounding generator expression early. Encode the directory id using
`(...)` instead.
Fixes: #20202
