allow dry run for builds with regeneration

[moritzx22]

Problem Description

The dry run ninja -n does not help very much if a regeneration is scheduled.
One common use case is globbing in cmake. See example below:

# CMakeLists.txt
cmake_minimum_required(VERSION 3.19)
project(hallo_cpp) 

file(GLOB TEST_SOURCES CONFIGURE_DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/*.cpp ) 
add_executable(tests ${TEST_SOURCES})

main.cpp is on the disk.

Master branch

$ touch main.cpp && ninja | tee
[0/2] Re-checking globbed directories...
[1/3] Building CXX object CMakeFiles/tests.dir/main.cpp.o
[2/3] Linking CXX executable tests

$ touch main.cpp && ninja -n | tee
[0/2] Re-checking globbed directories...
[1/2] Re-running CMake...

The dry run option -n is not very useful anymore.

Proposed solution

$ touch main.cpp && ninja -n | tee
[0/2] Re-checking globbed directories...
[1/2] Re-running CMake...
[1/4] Building CXX object CMakeFiles/tests.dir/main.cpp.o
[2/4] Linking CXX executable tests

The dry run is useful again.

[Samuelcatouillard]

pacman -S ninja

[jhasse]

If "Re-running CMake..." would produce a different build manifest the dry run may then be incorrect. Not sure if this is a deal breaker.

In general the "Re-checking globbed directories..." is a hack and we should find a better solution to support globbing. I've created #2709 just now to improve that situation.

[moritzx22]

In general the "Re-checking globbed directories..." is a hack and we should find a better solution to support globbing.

The “Re-checking globbed directories…” approach is definitely more of a workaround than a clean solution. I used globbing in my example simply because it’s something many developers are familiar with, so it makes ninjas regeneration and dry‑run behavior easier to demonstrate.

[moritzx22]

If "Re-running CMake..." would produce a different build manifest the dry run may then be incorrect. Not sure if this is a deal breaker.

It’s inherent to any dry‑run mechanism that it can’t be fully correct in all scenarios. During a real build, commands may generate new files, dyndeps can reshape the dependency graph, and other side effects can occur that a dry run simply cannot predict. The goal shouldn’t be perfect accuracy but usefulness—showing what Ninja plans to do, even if the actual build may differ.

Proposed solution

Based on and in contrast to #2707 (comment), here’s a simple case where a dry run cannot be correct and ends up not being useful:

$ls
a.cpp main.cpp
$ninja && mv a.cpp b.cpp
$ninja -n
[0/2] Re-checking globbed directories...
[1/2] Re-running CMake...
ninja: error: 'SOURCE_DIRECTORY/a.cpp', needed by 'CMakeFiles/tests.dir/a.cpp.o', missing and no known rule to make it

After the rename, a real build would regenerate the manifest and proceed, but the dry run can’t know that and instead reports an error.

Back to usefull

$cmake .
$ninja -n
usefull output again...