Split the test case from commit f50fb77a4f (Ninja: Regenerate when test
or install scripts are missing, 2024-10-29, v4.0.0-rc1~516^2) into a
dedicated case.
Corruption happens when a multiline help string starts with
a newline. This causes an overflow in substr() and the whole,
unescaped help string is written to the cache file.
Multiline strings are escaped line by line. The fix is to start
searching for line break points from position 1. A break point
at zero, which triggers the overflow, could only produce
a redundant empty line.
Fixes: #9098
Rerun CMake when `cmake_install.cmake` or `CTestTestfile.cmake` are out
of date. This enables regeneration if a subdirectory is removed before
invoking `ninja`.
Fixes: #26396
Since commit 18e1bfbb3c (cmake: On configure error suggest looking at
CMake*.log files, 2013-07-09, v2.8.12~210^2), when configuring a project
fails, we print `See also .../CMake{Output,Error}.log` near the end of
the output. This was intended to help users find failures in system and
compiler inspection checks, but for normal project errors the messages
may be misleading. The logs may contain incidental errors that are part
of normal operation and do not need to be addressed by the user.
Since commit f6ed2585e5 (Modules: Record system inspection steps in the
configure log, 2023-01-16), CMake's builtin modules no longer log
information to the old-style `CMake{Output,Error}.log` files anyway,
so stop mentioning them.
Fixes: #22131
Issue: #23200
We may want to enable these variables later on with specific
semantics. To avoid breaking backwards compatibility, make it an
error to use them for now.
Users or scripts commonly remove or replace `CMakeCache.txt` without
also removing `CMakeFiles/`. In this case the information saved in the
cache from platform information initialization is missing, so we need to
re-initialize it. In such a case, remove the platform information
directory so that re-initialization will occur and restore needed
information to the cache.
Closes: #14820
Since commit 14a8d61f (cmMakefile: Port nested error logic away from
cmExecutionStatus) we fail to continue processing function and macro
bodies after non-fatal errors. A non-fatal error should not stop
foreach loops, macro bodies, nested bodies, or the outer script.
Add a test covering these cases, and revert the change to fix them.
Also revert commit 2af853de (cmMakefile: Simplify IssueMessage
implementation) because the assertion it added (which was removed by the
above commit and is restored by reverting it) is incorrect. We do have
code paths that call cmMakefile::IssueMessage with an empty execution
stack, such as in CheckForUnusedVariables's LogUnused call.
After calls to ProcessSourceItemCMP0049, check for an empty return
string to detect a failure instead of trusting GetErrorOccuredFlag.
The latter could have been left from a preceding non-fatal error.
Extend the RunCMake.Configure test to cover a case that exposed this
problem.
Define a new 'CMAKE_CONFIGURE_DEPENDS' directory property that projects
can use to specify input files to the CMake configuration process.
Extend the RunCMake.Configure test to verify that the build system
re-runs CMake when this input changes.
Extend the RunCMake.Configure with a case to verify that the CMake
configuration process does not immediately re-run the first time that
the generated build system is invoked.
In CMakeDetermineCompilerABI we use try_compile with the COPY_FILE
option to get a copy of the compiled binary used to detect the ABI
information. We already tolerate the case when compilation fails.
However, when compilation appears to succeed but does not produce the
expected executable the try_compile command immediately reports an error
because the COPY_FILE fails.
Tolerate COPY_FILE failure without stopping the overall configuration
process by using the try_compile COPY_FILE_ERROR option to capture the
error message. Log the full error to CMakeError.log and simply report
failure to detect the ABI as if compilation had failed.
Teach the RunCMake.Configure test to cover this case and verify that the
messages show up as expected both in stdout and in CMakeError.log.
When CMake reports failure to configure a project, especially when the
toolchain does not initialize properly, the true reason may be clear
from reading the CMakeFiles/CMake(Output|Error).log files. Advise users
to look at these files if they exist when configuration fails.
Add RunCMake.Configure test to check that the log files are mentioned
when configuration fails.
