d92469e572 Help: Clarify how package resolve mode is intended to be used
f320a31087 cmake --build: prioritize --resolve-package-references over preset
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6984
a2cfa2da4f GenEx/LINK_LIBRARY: Add features for framework support on Apple
40178f3c90 cmGlobalGenerator: Add helper to split framework path
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6967
925da7d428 VS: Write ZERO_CHECK.proj for VS19 and above
11b8366e55 VS: Introduce IsInSolution to check whether a target is in sln file
0682cd3657 VS: Add proj as a project type to VsProjectType
6ab2c40c17 cmGlobalVisualStudio7Generator: Drop unused method
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6891
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".
Previously, different versions of VS Generators checked whether a target
was in .sln file or not by checking whether the target was to be written
to build system or not.
As we move `ZERO_CHECK.vcxproj` to `.proj`, we want to exclude those
files from being written to `.sln` files too. This commit introduces
`IsInSolution()` at `cmGlobalVisualStudioGenerator` level which can be
customized at specific versioned Generator when needed.
Add `proj` as a project type to VsProjectType so that it can be consumed
by `ZERO_CHECK` target. This commit adds the type and cleans up the code
that needs to treat `proj` and `csproj` in the same fashion. Next commit
will make changes to add `ZERO_CHECK.proj`.
Since commit f47b4f68a9 (Drop Visual Studio 7 generator for VS .NET
2002, 2016-03-10, v3.6.0-rc1~268^2), the `WriteTargetDepends` method has
not been used.
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
After !6954 got merged, it has become easier for tools to get
full stack-traces for runtime traces of a CMake program. The trace
information already included in the JSON objects (line number, source
file path) allows tools that display these stack traces to print the
CMake source code associated to them. However, CMake commands may
spawn multiple lines, and the JSON information associated to a trace
only contains the line in which the command started, but not the one
in which it ended. If tools want to print stack traces along the
relevant source code, and they want to print the whole command
associated to the stack frame, they will have to implement their own
CMake language parser to know where the command ends.
In order to simplify the life of those who want to write tooling for
CMake, this commit adds a `line_end` field to the json-v1 trace
format. If a given command spans multiple lines, the `line_end` field
will contain the line of the last line spanned by the command (that of
the closing parenthesis associated to the command).
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
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
To enable the management of incompatible $<LINK_LIBRARY> declarations,
add LINK_LIBRARY_OVERRIDE and LINK_LIBRARY_OVERRIDE_<LIBRARY> target
properties.
This generator expression offers the capability, for the link step, to
decorate libraries with prefix/suffix flags and/or adding any specific flag for each
library.
Fixes: #22812, #18751, #20078, #22703
Tools using the json-v1 format might want to trace stack frames across
different `CMakeLists.txt` files, in order to, for example, provide
stacktraces that span from the top-level `CMakeLists.txt` in a
project. One would think that `frame` lets you do that, but it
doesn't, because it tells you the depth of the stack within the
current `CMakeLists.txt`, so it gets reset across calls to
`add_subdirectory`.
The solution involves adding a field with a "global frame". This value
gets incremented on calls to `add_subdirectory`, which makes it easier
for tools to reconstruct "global stacktraces".
I considered changing the current "frame" value, but I didn't because
it would be a breaking change. I cannot think of any use-case where
"frame" is more useful to "global-frame", but maybe I'm missing
something.
* 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
