To clarify further, simply removing -o and using -n (--just-print) instead is also not a viable workaround. While -n would traverse the prerequisites and make the graph structurally complete, the reported target build statuses would be wrong for this use case. The debug output would show targets as 'needing to be remade' rather than treating them as up-to-date via the -o override.
There seems to be no combination of current options that yields both a fully traversed dependency graph and the correct target statuses in the debug logs. On Tuesday, May 26th, 2026 at 3:30 PM, WaitronCharm <[email protected]> wrote: > Hello, > > I am working on reconstructing the visual dependency graph of a build using > GNU Make's --debug output. However, I have run into a limitation when > combining debugging with the -o (--old-file) option. > > When a target is marked as old via -o, GNU Make seems to immediately optimize > away the traversal of that target's prerequisites. Because these > prerequisites are not traversed, they are completely omitted from the debug > log. This leaves the reconstructed visual graph incomplete. > > From an execution standpoint, optimizing out these checks makes perfect > sense. However, for tooling and visualization, it creates a blind spot. Could > the final decision to consider a target up-to-date (based on -o) be deferred > until after its prerequisites have been traversed in the graph? > > I tried using the -n (--just-print / dry-run) option as an alternative to see > the full graph without executing commands, but it has a different limitation: > rules that update included makefiles are still actively executed under -n. > > This leaves a gap in the current options. There appears to be no combination > of flags that allows a user to safely skip a target's execution while still > fully discovering and dumping its underlying dependency tree in the debug > output. > > Here is a minimal example demonstrating the behavior: > > $ make --debug -f - -o t1 > GNU Make 4.4.1 > Built for x86_64-pc-cygwin > Copyright (C) 1988-2023 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > t1: t2; echo $@ > t2:; echo $@ > Reading makefiles... > Updating makefiles.... > Updating goal targets.... > make: 't1' is up to date. > > Notice that t2 is never mentioned or evaluated in the debug output above. > Compare this to a normal run where the full relationship is explicitly > printed: > > $ make --debug -f - > GNU Make 4.4.1 > Built for x86_64-pc-cygwin > Copyright (C) 1988-2023 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > t1: t2; echo $@ > t2:; echo $@ > Reading makefiles... > Updating makefiles.... > Updating goal targets.... > File 't1' does not exist. > File 't2' does not exist. > Must remake target 't2'. > echo t2 > t2 > Successfully remade target file 't2'. > Must remake target 't1'. > echo t1 > t1 > Successfully remade target file 't1'. > > Is this immediate pruning of the graph an intentional design constraint for > performance, or would the maintainers consider a patch/option that forces > prerequisite traversal even when a target is short-circuited by -o? > > I would love to hear your thoughts on whether this use case is currently > supported through other means, or if a feature request is appropriate here. > >
