05e510bf0b CMP0132: Don't set compiler environment variables on first run
774a9eb210 Tests: Reorder CMP0129 test
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7108
When running CMake for the first time in a build tree, for some
generators CMake would set compiler environment variables
like CC, CXX, etc. when the corresponding language is enabled.
That behavior was never documented and can result in different
behavior between the first and subsequent runs. Add a policy
to no longer set those environment variables.
Fixes: #21378
In commit afcd9fe669 (AIX: Add an option to disable automatic exports
from shared libraries, 2020-01-30, v3.17.0-rc1~47^2) the population of
the `<AIX_EXPORTS>` rule variable placeholder was accidentally added to
the device linking rule rather than the main linking rule. This caused
our `ExportImportList` script on AIX, when called for executables with
`ENABLE_EXPORTS` set, to be given an `AIX_EXPORTS` file name that does
not exist, leading to a warning from the `dump` tool.
Move the population of the `<AIX_EXPORTS>` placeholder in the Makefile
generators to the main link rule.
Issue: #20290
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
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
Revert commit f3ad061858 (Add usage requirements to update direct link
dependencies, 2022-01-12, v3.23.0-rc1~44^2) and the property storage
updates in its predecessor commit 193a999cd5 (cmTarget: Add
INTERFACE_LINK_LIBRARIES_DIRECT{,_EXCLUDE} backtrace storage,
2022-01-06, v3.23.0-rc1~44^2~1) from the 3.23 release branch.
After initial experience using the feature in practice, additional
design considerations have been raised for discussion in the original
issue. To avoid rushing this for the 3.23 series, we've decided to
revert the feature for now so it can be revised for a future release.
Issue: #22496
