| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
38de1bef2d find_package: Improve --debug-find-pkg= when using a find module
d634d20397 find_package: Avoid printing debug output header multiple times
df3e29450a find_package: Mention package name in Config mode debug output
636ca7f25c find_package: Fix find module name in --debug-find output
596e185409 find_package: Improve formatting of --debug-find output
2f43527574 Tests: Improve order of RunCMake.find_package cases
a690523fcf cmFindPackageCommand: Drop ComputeIfDebugModeWanted overload
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !6973
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2a6b0415d7 $<LINK_LIBRARY>: Add LINK_LIBRARY_OVERRIDE target property
42965799b4 Genex: Add $<LINK_LIBRARY:...>
78dd7d5292 cmRulePlaceholderExpander: add base class for placeholder expansion reuse
4b55828a9f cmExpandListWithBacktrace: add handling of empty elements.
28d7432468 cmComputeLinkInformation: use cmComputeLinkDepends::LinkEntry
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6769
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|/
|
|
|
|
|
| |
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.16 and below to encourage projects to port
away from setting policies to OLD.
|
|
|
|
| |
Accept a `cmListFileFunction` instead of a `cmCommandContext`.
|
|
|
|
|
|
|
| |
Store the main dependency as the first entry in the dependency list plus
a boolean member indicating its existence. Note that this slightly
changes existing behavior: the main dependency was previously the last
entry of the dependency list.
|
|
|
|
|
| |
All uses of `GetBottom` by clients have been removed, so drop the
method and its supporting infrastructure.
|
|\
| |
| |
| |
| |
| |
| |
| | |
5b1ed2a646 try_compile: Do not use CMAKE_BUILD_TYPE or CMAKE_CONFIGURATION_TYPES env vars
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !6755
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since:
* commit e216b9bbd3 (cmake: Allow CMAKE_BUILD_TYPE to be set by
environment variable, 2021-06-29, v3.22.0-rc1~503^2~1)
* commit ef56eefc9b (cmake: Allow CMAKE_CONFIGURATION_TYPES to be set by
environment variable, 2021-06-29, v3.22.0-rc1~503^2)
the environment variables are supposed to provide defaults for settings
the user otherwise can control via cache entries. However, they
accidentally affect `try_compile` projects too, which are supposed to be
programmatically controlled.
Fixes: #22935
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Note 1: `detail::AddCustomCommandToTarget()` resets cc,
since cc is not moved away.
Note 2: In `detail::AddUtilityCommand()`, a few vars are preserved
before using. Their refs will be alive in most cases, but cc might
be destroyed in the future.
|
| | |
|
| |
| |
| |
| | |
Avoid repeating it at every call site.
|
| | |
|
|/
|
|
|
|
|
| |
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.15 and below to encourage projects to port
away from setting policies to OLD.
|
|
|
|
|
|
|
|
|
|
| |
Compilers based on EDG frontend sometimes throw
an internal error while using `this->` at some
circumstances. While it is up to be fixed in future
versions of front end, this bug still occurs in
some modern compilers, such as LCC for Elbrus CPUs,
and probably others (maybe ICC). It caused CMake to be
unbuildable by these compilers. This patch fixes it.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
f84193292c Use new AddCacheEntry signatures
3c2e58eeb8 AddCacheEntry accept cmProp or std::string
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6495
|
| | |
|
|/ |
|
| |
|
|
|
|
|
| |
Methods SetProperty of classes cmPropertyMap, cmStateDirectory
and cmMakefile accept now cmProp or std::string as argument.
|
|
|
|
|
|
| |
To handle safely the values used by CMake variables and properties,
introduce the class cmProp as a replacement from the simple pointer
to std::string instance.
|
|
|
|
|
| |
Construct with the project kind instead of mutating state after
construction.
|
|
|
|
| |
`CreateNewTarget` tells whether the target is inserted or not.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ef56eefc9b cmake: Allow CMAKE_CONFIGURATION_TYPES to be set by environment variable
e216b9bbd3 cmake: Allow CMAKE_BUILD_TYPE to be set by environment variable
6986a382a9 Help: Document when CMAKE_BUILD_TYPE and CMAKE_CONFIGURATION_TYPES are set
e96169a3ec Help: Cross-reference CMAKE_CONFIGURATION_TYPES from CMAKE_BUILD_TYPE
03bd9c4c10 cmMakefile: Add helper to initialize CMAKE_CONFIGURATION_TYPES
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6291
|
| |
| |
| |
| |
| |
| |
| |
| | |
When no `CMAKE_CONFIGURATION_TYPES` is explicitly specified while
creating a new build tree, check for an environment variable of the same
name.
Issue: #20983
|
| |
| |
| |
| |
| | |
Factor out duplicate code from the Ninja Multi-Config, Visual Studio,
and Xcode generators.
|
|/
|
|
|
|
|
| |
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.14 and below to encourage projects to port
away from setting policies to OLD.
|
|
|
|
| |
Fixes: #22353
|
|
|
|
|
| |
Model the change after commit 089868a244 (cmState: Record buildsystem
target names in each directory, 2016-09-16, v3.7.0-rc1~79^2~3).
|
|
|
|
| |
`AddTargetObject` knows the location of object files.
|
|\
| |
| |
| |
| |
| |
| |
| | |
d96eb55282 set(CACHE): do not remove normal variable
Acked-by: Kitware Robot <kwrobot@kitware.com>
Reviewed-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !6146
|
| |
| |
| |
| | |
Fixes: #22038
|
|\ \
| |/ |
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
08db1341a6 find_*: ensure consistent behavior for cache variables
f5fa6d53b0 class cmake: Store working directory at cmake launch
b1729200c3 find_*: refactor cache variable handling
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6110
|
| | |
| | |
| | |
| | | |
Fixes: #22121
|
| |/ |
|
| | |
|
| |
| |
| |
| | |
Fixes: #20553
|
| |
| |
| |
| |
| | |
These extensions are used by convention for C++ modules and interface
units with MSVC.
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
339dbc901f Help: Note that CMP0116 is recorded at the time of CC creation
e3740e020e Tests: Test Qt autogen target with CMP0116 set to WARN
cf34011ce7 Tests: Test per-CC behavior of CMP0116
3a95503512 Ninja: Use CMP0116 status recorded at time of custom command's creation
f01f10e8fb cmCustomCommand: Record value of CMP0116 at time of creation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5848
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.13 and below to encourage projects to port
away from setting policies to OLD.
|
| |/
|/|
| |
| | |
Fixes: #22234
|