Re: Question/Proposal: Incomplete debug graph output when using -o (--old-file)

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 statuse=
s 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 o=
verride.

There seems to be no combination of current options that yields both a full=
y traversed dependency graph and the correct target statuses in the debug l=
ogs.

On Tuesday, May 26th, 2026 at 3:30 PM, WaitronCharm <[email protected]=
> wrote:

> Hello,
>=20
> I am working on reconstructing the visual dependency graph of a build usi=
ng GNU Make's --debug output. However, I have run into a limitation when co=
mbining debugging with the -o (--old-file) option.
>=20
> When a target is marked as old via -o, GNU Make seems to immediately opti=
mize away the traversal of that target's prerequisites. Because these prere=
quisites are not traversed, they are completely omitted from the debug log.=
 This leaves the reconstructed visual graph incomplete.
>=20
> From an execution standpoint, optimizing out these checks makes perfect s=
ense. However, for tooling and visualization, it creates a blind spot. Coul=
d the final decision to consider a target up-to-date (based on -o) be defer=
red until after its prerequisites have been traversed in the graph?
>=20
> 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 limi=
tation: rules that update included makefiles are still actively executed un=
der -n.
>=20
> This leaves a gap in the current options. There appears to be no combinat=
ion of flags that allows a user to safely skip a target's execution while s=
till fully discovering and dumping its underlying dependency tree in the de=
bug output.
>=20
> Here is a minimal example demonstrating the behavior:
>=20
> $ 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.
>=20
> 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 pri=
nted:
>=20
> $ 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'.
>=20
> Is this immediate pruning of the graph an intentional design constraint f=
or performance, or would the maintainers consider a patch/option that force=
s prerequisite traversal even when a target is short-circuited by -o?
>=20
> 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.
>=20
>