summaryrefslogtreecommitdiffstats
path: root/Tests/RunCMake/Configure/RunCMakeTest.cmake
Commit message (Collapse)AuthorAgeFilesLines
* cmake: Stop pointing users at logs on configure errorsBrad King2023-01-191-1/+0
| | | | | | | | | | | | | | | | | | 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
* try_compile: Record output location instead of reverse computing itRobert Maynard2022-09-071-1/+1
| | | | Fixes #23887, #23942, #20163, #18288
* Generator: Don't allow Ninja Multi-Config variables on other generatorsKyle Edwards2020-02-271-0/+6
| | | | | | 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.
* VS: Fix access violation when calling Visual Studio macroDaniel Eiband2019-09-241-0/+17
| | | | Fixes: #19730
* Tolerate removed/replaced CMakeCache.txt with old CMakeFiles/Brad King2016-11-171-0/+9
| | | | | | | | | | | 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
* cmMakefile: Restore nested error logic use of cmExecutionStatusBrad King2016-09-061-0/+1
| | | | | | | | | | | | | | 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.
* cmTarget: Do not mistake a preceding error for a CMP0049 failureBrad King2014-07-301-0/+1
| | | | | | | | | 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.
* Allow projects to specify extra inputs to CMakeBrad King2014-01-211-0/+5
| | | | | | | 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.
* Add test case to verify CMake does not re-run on first buildBrad King2014-01-211-0/+15
| | | | | | 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.
* Teach compiler ABI check to tolerate try_compile COPY_FILE failureBrad King2013-07-171-0/+1
| | | | | | | | | | | | | | | | | 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.
* cmake: On configure error suggest looking at CMake*.log filesBrad King2013-07-091-0/+3
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.