Since commit c1e812ad4f (target_link_libraries: Improve tolerance of
unquoted generator expressions, 2022-02-15, v3.23.0-rc2~11^2) we
accumulate consecutive non-keyword arguments to recover an unquoted
generator expression as a single entry. When given multiple consecutive
non-genex library names, the grouping breaks our logic that expects each
entry is either a raw target name or a genex. Revise the logic to only
accumulate multiple arguments when they end inside a partial genex.
This bug caused `target_link_libraries` to stop wrapping static library
private dependencies in `$<LINK_ONLY:...>` for `INTERFACE_LINK_LIBRARIES`
when multiple consecutive library names are given. Add a test case
covering that behavior.
Fixes: #23302
Since commit 880ca66b51 (Fix: `while()` can silently ignore incorrect
condition, 2021-08-09, v3.22.0-rc1~238^2~4) we correctly reject the
code
set(paren "(")
while(${paren})
endwhile()
However, rejecting it breaks compatibility with projects that used such
code accidentally. In CMake 3.21 and below, any error in the condition
was ignored because the `false` result exited the loop first. Restore
tolerance of the error for now. A policy will be needed to make it an
error later.
Note that the same condition with `if` was always correctly rejected.
Fixes: #22524
Issue: #23296
Co-authored-by: Brad King <brad.king@kitware.com>
Refactor the logic checking `CMAKE_CUDA_ARCHITECTURES` special values.
Switch on the value first, and then make other decisions for each case.
This makes room for other special values to be added later.
There's no point printing a blank line if FindHeaderInFramework()
returns an empty string. Pass in the debug object to that function
instead so it can record the actual paths it tests in the debug output
directly.
Since commit 8f64df0a7c (CUDA: Generic all and all-major support,
2021-12-19, v3.23.0-rc1~23^2), setting `CUDA_ARCHITECTURES` to a value
other than `all` or `all-major` is ignored with NVCC 11.5+. Fix the
logic to return early only when actually using an "all" value.
Fixes: #23243
When given two source paths via `-S` or just directory paths prefer
the last one. When the paths are mixed always prefer the last `-S`
entry.
Fixes: #23238
f73457ca2e cmake: Ignore any empty "" command line arguments
67f97f5478 Tests: Add RunCMake helper to run cmake with raw execute_process args
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6980
Prior to commit 1d709ea2f5 (cmGeneratorTarget: Propagate backtraces from
INTERFACE_LINK_LIBRARIES, 2021-12-15, v3.23.0-rc1~228^2), the value of
`INTERFACE_LINK_LIBRARIES` was a single string. If an unquoted
generator expression passed to `target_link_libraries` contained `;` and
became multiple arguments, they would all accumulate as a single
`;`-separated list in the value of `INTERFACE_LINK_LIBRARIES`. Since
that commit, each argument to `target_link_libraries` is placed in
`INTERFACE_LINK_LIBRARIES` as a separate entry, as has long been the
case for `LINK_LIBRARIES`. That behavior change broke projects that were
accidentally relying on accumulation in `INTERFACE_LINK_LIBRARIES` to
produce complete generator expressions containing `;`.
Teach `target_link_libraries` to accumulate consecutive non-keyword
arguments into a single entry before placing them in `LINK_LIBRARIES` or
`INTERFACE_LINK_LIBRARIES`. For example, treat `a b c` as if they were
written as `"a;b;c"`. This restores the previously accidental support
for unquoted generator expressions in `INTERFACE_LINK_LIBRARIES`, and
also enables it for `LINK_LIBRARIES`.
For now, do not drop the `target_link_libraries` documentation that
recommends quoting generator expressions. Quoting is still important to
populate `LINK_LIBRARIES` in CMake 3.22 and below, and is also good
practice to keep generator expressions whole.
Fixes: #23203
Since commit daa6d2bc04 (ENH: updated handling of debug and optimized
target link libraries, 2006-11-29, v2.6.0~2471) the ancient
`<lib>_LINK_TYPE` compatibility lookup was done using the name of the
dependent target for which `target_link_libraries` is called, rather
than the name of the library dependency being considered. This code
probably does nothing. Remove it.
The argument name used in the class declaration didn't match the one
used in the implementation file. The one in the header appears to be a
cut-n-paste from GetDebugFindOutput(), but the implementation makes
it clear that "pkg" better infers what the argument represents than "var".
Extend the feature added by commit d7b18895bc (cmake: Add filtered
debug-find options, 2021-12-07, v3.23.0-rc1~217^2) to enable debug
output for `find_*` calls within a find module or cmake package
configuration file.
Fixes: #23211
The overload for `--debug-find-pkg` has the same signature as the base
class method for `--debug-find-var`. To avoid confusion, drop the
overload and inline it its only call site.
In commit 55e4753bbb (Refactor cmTargetExport removing
InterfaceIncludeDirecories, 2021-07-20, v3.22.0-rc1~337^2~1) the storage
of `INCLUDES DESTINATION` was moved into each target. However, a target
may be installed in multiple exports, and their `INCLUDES DESTINATION`
should not be mixed.
Convert the IncludeDirectoriesEntries vector to a map and modify access
function to store the directories lists with respect to cmExportTarget
object. This fixes error when the same target is exported more than once
via different exports and each for consequent export its include
directories list grows. Add a test for this case.
Fixes: #23183
5cdd774d51 VS: Handle build target correct for .NET SDK style projects with Any CPU
309191052c VS: Set Visual Studio versions read out from solution file
f7791698cb VS: Allow setting output directory in .NET SDK style projects
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6944
* Extend Visual Studio solution parser for reading build target
* Map solution build target to project build target (especially for Any CPU)
* Use C++ <optional> template instead of pointer return value for cmSlnData::GetProjectByGUID
This was accidentally left out of commit 736663deed (Begin 3.23 release
versioning, 2022-02-03). The step is documented as part of the release
branching process in the CMake Maintainer Guide `Help/dev/maint.rst`.
