mirror of
https://github.com/reactos/CMake.git
synced 2025-02-20 20:00:52 +00:00
7c36d2067b
Since commit v3.4.0-rc1~321^2~2 (Genex: Store a backtrace, not a pointer to one, 2015-07-08) we treat cmListFileBacktrace instances as lightweight values. This was true at the time only because the backtrace information was kept in the cmState snapshot hierarchy. However, that forced us to accumulate a lot of otherwise short-lived snapshots just to have the backtrace fields available for reference by cmListFileBacktrace instances. Recent refactoring made backtrace instances independent of the snapshot hierarchy to avoid accumulating short-lived snapshots. This came at the cost of making backtrace values heavy again, leading to lots of string coying and slower execution. Fix this by refactoring cmListFileBacktrace to provide value semantics with efficient shared storage underneath. Teach cmMakefile to maintain its call stack using an instance of cmListFileBacktrace. This approach allows the current backtrace to be efficiently saved whenever it is needed. Also teach cmListFileBacktrace the notion of a file-level scope. This is useful for messages about the whole file (e.g. during parsing) that are not specific to any line within it. Push the CMakeLists.txt scope for each directory and never pop it. This ensures that we always have some context information and simplifies cmMakefile::IssueMessage. Push/pop a file-level scope as each included file is processed. This supersedes cmParseFileScope and improves diagnostic message context information in a few places. Fix the corresponding test cases to expect the improved output.
If you think about adding a new testcase then here is a small checklist you can run through to find a proper place for it. Go through the list from the beginning and stop once you find something that matches your tests needs, i.e. if you will test a module and only need the configure mode use the instructions from section 2, not 3. 1. Your testcase can run in CMake script mode, i.e. "cmake -P something" Put your test in Tests/CMakeTests/ directory as a .cmake.in file. It will be put into the test binary directory by configure_file(... @ONLY) and run from there. Use the AddCMakeTest() macro in Tests/CMakeTests/CMakeLists.txt to add your test to the test runs. 2. Your test needs CMake to run in configure mode, but will not build anything This includes tests that will build something using try_compile() and friends, but nothing that expects add_executable(), add_library(), or add_test() to run. If the test configures the project only once and it must succeed then put it into the Tests/CMakeOnly/ directory. Create a subdirectory named like your test and write the CMakeLists.txt you need into that subdirectory. Use the add_CMakeOnly_test() macro from Tests/CMakeOnly/CMakeLists.txt to add your test to the test runs. If the test configures the project with multiple variations and verifies success or failure each time then put it into the Tests/RunCMake/ directory. Read the instructions in Tests/RunCMake/CMakeLists.txt to add a test. 3. If you are testing something from the Modules directory Put your test in the Tests/Modules/ directory. Create a subdirectory there named after your test. Use the ADD_TEST_MACRO macro from Tests/CMakeLists.txt to add your test to the test run. If you have put your stuff in Tests/Modules/Foo then you call it using ADD_TEST_MACRO(Module.Foo Foo). 4. You are doing other stuff. Find a good place ;) In doubt mail to cmake-developers@cmake.org and ask for advise.