Re: toolchain/60435: "make depend" is too fussy

The following reply was made to PR toolchain/60435; it has been noted by GNATS.

From: Taylor R Campbell <[email protected]>
To: Robert Elz <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: toolchain/60435: "make depend" is too fussy
Date: Fri, 10 Jul 2026 18:59:37 +0000

 > From: Robert Elz <[email protected]>
 > Date: Fri, 10 Jul 2026 07:00:00 +0000 (UTC)
 > 
 > Then when we come to do the actual build, make will see that b.h
 > doesn't exist, and use the recipe it has been given to build it.
 > Since b.h will then be newer than any possibly existing a.o, that
 > will need to be rebuilt.   All make needed to be aware of is that
 > something required a.c to be recompiled, and then do it - how many
 > other include files b.h might have included is irrelevant, it is
 > going to be recompiled anyway.
 > 
 > Note this is not a case where different dependencies missing or out
 > of date cause different build scripts to be run, a.o will be being
 > rebuilt after b.h is made, because of b.h being out of date, always,
 > here.   Any other dependencies that could have been extracted from
 > b.h could not alter that.
 
 The transitive dependencies of b.h may not affect the _first_ build of
 a.o, but they will affect _subsequent_ builds of a.o.  E.g., suppose
 b.h includes <machine/mcontext.h>, and you run:
 
 $ make depend
 (generates a.d)
 $ make
 (compiles a.o)
 $ edit sys/arch/amd64/include/mcontext.h
 
 Then a subsequent `make' should trigger recompiling a.o, but the only
 way for make(1) to know this is if b.h already exists when mkdep(1)
 runs so it can discover the dependency on machine/mcontext.h.
 
 We could use `cc -M -MF $*.d' in the .o rule in order to regenerate
 the .d file at the same time, but we don't.  It also wouldn't help if
 a.c includes b.h and b.h includes c.h and _both_ b.h and c.h have to
 be generated.
 
 (Note that we would need that _in addition to_ a more lenient
 mkdep(1), or else the makefile would still not know that it has to
 generate b.h before it can compile a.c -> a.o.)