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
The fix in commit e4f1b301fe (cmake: Allow arbitrary args passed to
CMake script, 2020-05-04, v3.18.0-rc1~211^2) only applied to "cache"
arguments like `-DFOO`. Extend the fix to allow arbitrary arguments
that collide with other CMake arguments like `-S` and `-B`.
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
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).
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.
Implements a -- delimiter, that indicates the end of options (starting
with a dash -) of a command and separates them from the subsequent
operands (positional arguments).
The following commands are affected:
- env: Implemented the -- delimiter.
- cat: The -- delimiter was already kind of considered, but its
occurence did not stop the options parsing.
- rm: Here the command already implemented the -- delimiter as
specified, but it was not documented.
Fixes#22970
RunCMake/CommandLine has problems
when ran using language setting differeng from English. This is due to
test outputs being compared to English strings, which comparison
obviously fails if this language is set to, e.g. Russian. This commit
sets locale as "C" prior to running these tests, so messages while
testing are generated in correct language and do not fail checks
anymore.
Documentation added by
* commit 4f4f2028b8 (Help: Add documentation for buildPresets and
testPresets, 2021-01-13, v3.20.0-rc1~51^2~7)
* commit 676ecf0d37 (cmake-presets: Add build and test presets,
2020-12-14, v3.20.0-rc1~51^2~6)
used square brackets in the `cmake --build` signature to indicate
non-optional alternatives, which is not a typical convention.
A common convention is to use parentheses instead, but in this
case it is probably clearer to list the two signatures separately.
Fixes: #22413
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
f78b167a23 cmCommandLineArgument: Provide more information syntax error messages
5aa0dec6b0 cmake: `--build` and `--install` error out when encountering bad flags
928cdb17c5 cmCommandLineArgument: Correctly record parsing failures
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6119
In commit 7f89053953 (cmSystemTools: Return KWSys Status from CreateLink
and CreateSymlink, 2021-04-15) we just took the `-err` from libuv and
treated it as a POSIX error. This is accurate on POSIX, but on Windows
does not match the POSIX error codes.
Use `uv_fs_get_system_error` to get the actual system error code.
This requires libuv 1.38 or higher. Require that for Windows, but
fall back to the previous approach on POSIX.
