The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.18 and below to encourage projects to port
away from setting policies to OLD.
cmMakefile::EnableLanguage() now deduplicates the languages argument and
emits an author warning listing the languages that were defined multiple
times in a single call.
Fixes: #23596
In commit 731369ef9c (ENH: try to initialize all languages at the same
time, 2004-08-27, v2.4.0~2899) the languages parameter name for
cmMakefile::EnableLanguage() was changed to "std::vector languages" in
the declaration, however the definition had "std::vector lang".
Furthermore, the variable names in the definition had confusing names,
such as the "i" variable in the loop which referred to an iterator at
one point, but no longer does.
The new sub-command writes a string representation of the
current log level to the output variable given to the
sub-command.
Given that the log-level might be set either via the --log-level
command line option or via the CMAKE_MESSAGE_LOG_LEVEL
cache / regular variables, the priority for each of the log level
sources is as follows, with the first one being the highest:
1) --log-level
2) CMAKE_MESSAGE_LOG_LEVEL regular variable
3) CMAKE_MESSAGE_LOG_LEVEL cache variable
4) default log level (STATUS)
Fixes: #23572
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.17 and below to encourage projects to port
away from setting policies to OLD.
Rename the booleans 's_ErrorOccured' and 's_FatalErrorOccured' to
's_ErrorOccurred' and 's_FatalErrorOccurred', respectively.
Rename the getters and setters to 'Get[Fatal]ErrorOccurred' and
'Set[Fatal]ErrorOccurred', and fix all uses across the codebase.
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
Allow find package to promote scope of imported targets by specifying
an argument to `find_package` or by specifying a CMake variable.
* Add support for CMAKE_GLOBAL_IMPORT_SCOPE variable
* Add support for GLOBAL argument to find_package
Additionally add testing for above features.
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).
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.
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.
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.
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.
Vitaly Stakhovsky