How can I measure and diagnose performance bottlenecks in CMake's configure and generate steps?

When CMake configuration and generation become slow in large projects, a systematic measurement approach helps pinpoint where time is spent. The following steps outline a conservative, reproducible method that relies on built‑in CMake tracing and common timing utilities. Because the supplied sources do not contain CMake‑specific information, this answer is presented as a draft for human review; verify each step on your own system before applying optimizations.

1. Isolate the build tree: Create a clean temporary directory for each measurement run to avoid caching effects.
2. Capture a baseline timing: Use the shell time command (or hyperfine for more precise statistics) around a plain CMake invocation:

   time cmake -S . -B build

   Record the real, user, and sys times.
3. Enable CMake tracing: Re‑run the configuration with --trace to emit a line for every CMake command executed, prefixed with a timestamp:

   cmake --trace -S . -B build 2> trace.log

   The trace file contains entries like [ 0.123456s] add_subdirectory(...).
4. Optional: Expanded tracing: If macro expansion obscures the true source of work, add --trace-expand to see the fully expanded commands:
5. Parse the trace: Use a simple script (e.g., awk or Python) to aggregate time spent per CMake command or per directory:awk -F'\] ' '{print $2}' trace.log | sort | uniq -c | sort -nr This yields a ranked list of the most frequent or time‑heavy operations.
6. Identify hotspots: Look for patterns such as many file(GLOB) calls, heavy find_package searches, or repeated add_subdirectory traversals of large source trees.
7. Apply targeted mitigations:
   • Replace file(GLOB) with explicit source lists.
   • Cache find_package results via CMAKE_PREFIX_PATH or find_package(... QUIET) and avoid repeated calls.
   • Restructure deep directory hierarchies or use add_subdirectory guards to prevent re‑processing.
   • Consider using --parallel (CMake 3.12+) to allow concurrent processing of independent subdirectories.
8. Verify improvement: Repeat the baseline timing measurement after each change. A reduction in real time confirms the mitigation’s effect.
9. Rollback plan: Keep a copy of the original CMakeLists.txt files (or use version control) so you can revert to the previous state if a change introduces regressions.

Assumptions: The project uses a standard out‑of‑source build, the shell provides time or similar, and the CMake version supports --trace and --trace-expand. External profilers (e.g., perf, valgrind, or sampling tools) can be attached to the CMake process for deeper insight, but they are optional for initial bottleneck discovery.