`lfortran` < 1.24 uses `fccn`, a Fortran-to-C converter that
incorrectly handles long filenames that are more than 128 characters
long; so to check if Fortran can compile something, CMake must be
run in binary directory that has a name of less that 35 characters long.
It is ok for typical runs line `cmake -S . -B build` or `cmake ..`,
but does not work with usual CDash dashboard testing paths.
All this is not a problem for modern LCC >= 1.24.
2c6ec6de15 Link to transitive dependencies on stub libraries only on some linkers
dd4a6dff92 Link explicitly to private transitive dependencies on stub libraries
5f1bbdb3b3 Tests: Enable RunCMake.RuntimePath test on more platforms
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9050
This was missed in commit ca5a300d7f (add_test: Honor
CROSSCOMPILING_EMULATOR only when cross-compiling, 2023-11-02) when it
slipped from the 3.28 release.
As the 'char' type may be either signed, or unsigned, there are some
clashes between C Standard library functions and actual characters while
casting it to int directly. In case the 'char' type was signed, the
casted to int result value may be extended to full negative digit which
may be out of range of isspace() function (e.g. , for MSVC
implementation, which checks it for '> -1', and throwing an assertion
failure on fail).
Fixes: #25561
Instead of stating that the default is the native compilers,
say we will use the compilers from the preset. This makes it
more clear that the preset is working as expected.
Since ff6234509e (Help: Clarify behavior of INHERITED properties, 2018-03-21),
the docs for some get_..._property() commands incorrectly describe
the behavior for inherited properties. When a property is not set, even
in a parent scope, the returned result from the get_..._property()
command is the same whether the property is inherited or not.
The docs incorrectly stated that an empty string would be returned
for inherited properties in such cases.
Property-related commands used a mix of <VAR>, <var>, or
<variable> to specify the variable to store the result in. The <VAR>
form is particularly confusing, since being uppercase it looks more
like a keyword. Use <variable> consistently across all the commands
so that the behavior is clear.
The swift toolchain leaves output files untouched
if there are no meaningful input changes; without
restat, this causes ninja to needlessly rebuild
targets that are not actually out-of-date
Fixes: #25496
On some machines running many tests concurrently, the `INACTIVITY_TIMEOUT`
cases do not always complete within their individual timeout. Add an
undocumented cache entry to use on those machines to run the test serially.
We represent stub libraries, e.g., for CUDA, using imported `SHARED`
library targets with only `IMPORTED_IMPLIB`, and no `IMPORTED_LOCATION`,
to indicate that the stub file is meant only for linkers and not dynamic
loaders. See commit 7351d590ee (cmTarget: Add a way to represent
imported shared library stubs, 2023-07-17, v3.28.0-rc1~344^2) and commit
fc6508921c (cmComputeLinkInformation: Restore soname lookup for
non-imported targets, 2023-12-05, v3.28.0~4^2).
If a shared library is linked to a stub, it has a `NEEDED` field
populated with the `SONAME` found in the stub. When a dependent target
links to such a shared library, some linkers want to find a library file
on disk and load it to see what symbols it provides. This is necessary
for linkers that enforce `--no-allow-shlib-undefined`. On hosts with
only the stub library installed, e.g., with only the CUDA toolkit
development package, the real runtime library corresponding to the
stub's `SONAME` may not even exist, so no `-rpath-link` flag can help
linkers find it. Pass the stub library to linkers explicitly so they
can find it without searching.
459d1cc095 Tests: Verify that linker tool is detected and identified where expected
6aec4739c1 LinkerId: Record detection steps to configure log
ba5f8dbba3 LinkerId: Use empty string for unknown linker id
6cbd0658c5 LinkerId: Match Apple linker on all Apple platforms
9324668517 LinkerId: Fix detection of GNU linker id without parenthesis in version output
37bc148870 LinkerId: Fix detection of linker tool without path
6e527c2d38 LinkerId: Fix detection of linker tool for Clang on OpenBSD
455aed3061 LinkerId: Fix detection of linker tool for MSVC
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9086
