toolchain/60435: "make depend" is too fussy

["kre%munnari.OZ.AU@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60435
>Category:       toolchain
>Synopsis:       "make depend" is too fussy
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    toolchain-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 10 07:00:00 +0000 2026
>Originator:     Robert Elz
>Release:        NetBSD 11.99.6
>Organization:
>Environment:
System: NetBSD jacaranda.noi.kre.to 11.99.6 NetBSD 11.99.6 (JACARANDA:1.1-20260627) #287: Sun Jun 28 03:17:40 +07 2026 kre%jacaranda.noi.kre.to@localhost:/usr/obj/testing/kernels/amd64/JACARANDA amd64
Architecture: x86_64
Machine: amd64
>Description:
	If we have a file a.c

		#include "b.h"

		int func(void);

		func(void) {
			return B_VERSION;
		}

	but have no b.h, as that is to be built as part of the build process,
	with the Makefile containing (inter alia):

		b.h: ${VARIOUS_FILES}
			${SOME_COMMAND} ${VARIOUS_FILES} > b.h

	for example, and then we "make depend" (for the first time),
	currently the make depend fails, as b.h doesn't (yet) exist.

	I kind of understand the intent here, without b.h we can't know what
	other files it might include, which then a.c would also depend upon.

	Seems rational, but that is nonsense.   All we need to know, for now,
	is that a.c depends upon b.h and that is what the a.d dependency
	file should show.

	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.

	If we then clean up everything (including b.h) then the next time
	we build, all the same happens again, and all is good.

	If we don't clean, and just do another build, then make sees that
	b.h is newer than the a.d, and as a.d includes a dependency upon b.h
	it looks just like any other case where an include file might
	have been edited - perhaps causing the list of files it includes
	to alter.  In that case, make needs to rebuild a.d to get the
	current list of dependencies - and it would do that in our case
	too.  This time b.h does exist, and anything it includes will
	be discovered, just as if it had been there the first time, and
	a new dependency list for a.o is now made, with the full list
	of b.h and everything it includes.

>How-To-Repeat:
	Just go and (locally) revert change 1.229 "Properly fix the libc build"
	from src/lib/libc/gen/Makefile.inc

	Then make sure the OBJDIR for libc is empty (or doesn't exist
	at all), and attempt a build.

	Expect abject failure.    That should not happen, we should
	not need to explicitly add the nonsense explicit dependency info
	that that change added.   That's the whole point of "make depend".

	Note that if a build is done with 1.229 in place, and then
	that is reverted, and an update build (-u) is performed, all will
	work, as the "missing file" is no longer missing - until everything
	is cleaned next, then the following build would fail.   (BTDT).

>Fix:
	No idea, the make system is black magic as far as I'm concerned.