There have been two bugs reported about the `else` and `elseif`
commands in the context of the tracing functionality and the json-v1
format (#23191#22315). In essence, the reported traces referred to
the layer of the stacktrace immediately on top of the expected ones.
This MR fixes both issues. My solution adds a new parameter to the
`PrintCommandTrace` function, `commandMissingFromStack`, that callers
can specify if the command they want to report a trace for is not a
regular part of the stack maintained in `cmMakefile`. This is only the
case for `else` and `elseif`. The other bug is fixed by having the
caller pass a `cmListFileBacktrace`, which helps in getting the right
lines, file names... for the reported command.
Fixes: #23191#22315
Variable CMAKE_LINK_(LIBRARY|GROUP)_USING_<FEATURE>_SUPPORTED is evaluated
only if CMAKE_<LANG>_LINK_(LIBRARY|GROUP)_USING_<FEATURE>_SUPPORTED is not defined.
This new behavior enable to activate a feature globally on a platform and to disable
it for some compilers and languages.
Previously we always used content guarded by `$<LINK_ONLY:...>`
in `LINK_LIBRARIES`, even when evaluating for non-linking usage
requirements. Add a policy to honor `LINK_ONLY` in `LINK_LIBRARIES`
the same way we already do in `INTERFACE_LINK_LIBRARIES`.
Similar to GNU tar add a --touch option to the tar extract command to
skip extracting the timestamps from the files in the archive
effectively touching them as if they were just created.
Issue: #22746
Remove the requirement that the variable name have a prefix while
keeping the suffix requirement. Require that the property name
contains an underscore. Update docs and tests accordingly.
Fixes: #23340
This commit changes the indentation of lines which contain only closing
parentheses (`)`).
Example:
Change
```
add_library(mylib
mysrc.c
)
```
to:
```
add_library(mylib
mysrc.c
)
```
There are edge cases, where the indentation still doesn't really work.
Example:
This, admittedly weird, piece of code (manually formatted to what I would
expect - this is already a personal preference ...):
```
if(4)
if((0 OR 1
)
) # could also be aligned with the `i` in `if`
set(foobar
)
endif()
set(foobar)
endif()
```
will be changed to:
```
if(4)
if((0 OR 1
)
)
set(foobar
)
endif()
set(foobar)
endif()
```
whereas with the previous vim indentation code the result would have been:
```
if(4)
if((0 OR 1
)
)
set(foobar
)
endif()
set(foobar)
endif()
```
which is not great but better than above. I hope that this is acceptable.
Note: Apart from the actual indentation fixes, I based the change on a version
of indent/cmake.vim I found in the debian/bookworm vim82 package which is newer
than the one in the cmake repository (with `Last Change: 2017 Sep 24` comment
instead of the cmake repo version with `Last Change: 2017 Aug 30`).
This vim82/debian version moved these two lines:
```
let s:keepcpo= &cpo
set cpo&vim
```
a bit further down (after an early exit check - which seems to make sense to
me).
Fixes: #22394
In commit f3ad061858 (Add usage requirements to update direct link
dependencies, 2022-01-12, v3.23.0-rc1~44^2), we evaluated the transitive
closure of `INTERFACE_LINK_LIBRARIES` as a non-linking usage requirement.
That left out `INTERFACE_LINK_LIBRARIES_DIRECT` link dependencies that
appear behind private dependencies of a static library, guarded by the
`$<LINK_ONLY:...>` generator expression. At the time, that decision was
intentional, in order to prevent arbitrary usage requirements from
leaking out of `PRIVATE` dependencies.
Since then, we've revised evaluation of `LINK_LIBRARIES` to distinguish
between collecting link dependencies and other usage requirements. Use
that information when following `INTERFACE_LINK_LIBRARIES` to collect
the matching kind of requirements from `INTERFACE_LINK_LIBRARIES_DIRECT`.
Fixes: #22496
We evaluate `LINK_LIBRARIES` and `INTERFACE_LINK_LIBRARIES` for two purposes:
* Constructing the link line.
* Collecting usage requirements.
We evaluate `INTERFACE_LINK_LIBRARIES` separately for each purpose in
order to support the `$<LINK_ONLY:...>` generator expression used to
express private link dependencies of a static library. Previously we
only evaluated `LINK_LIBRARIES` for linking, and used that result for
collecting usage requirements too. Therefore `$<LINK_ONLY:...>` does
not work in `LINK_LIBRARIES`.
With the introduction of `INTERFACE_LINK_LIBRARIES_DIRECT`, evaluation
of `LINK_LIBRARIES` now needs to distinguish these two cases in order to
honor link dependencies encountered through `$<LINK_ONLY:...>` without
also exposing other usage requirements through private dependencies of a
static library. Revise internal infrastructure to distinguish the two
cases when evaluating `LINK_LIBRARIES`. Make the information available
in code paths for `INTERFACE_LINK_LIBRARIES_DIRECT` and `LINK_ONLY`.
Defer actually using the information to later commits.
Issue: #22496
Use the "ours" merge strategy because we only want to revert the change
from the 3.23 branch, not from `master`. It will be revised for
inclusion in a future release series.
Manually remove the 3.23 release note that would have been removed by
this merge without the "ours" strategy.
97f4aa1f05 ci: Add OpenJDK to Debian and Fedora base images
78d0613695 ci: Drop p4 binary checksum because the download URL is not stable
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7102
8468dfb35f FindMatlab: Use -batch option in matlab_add_unit_test if possible
ebb0685824 FindMatlab: Add fallback to use -batch option in version extraction
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7088
Craig Scott