Re: Make 4.3 rebuilds .o files when unnecessary

[Paul Smith]

On Sun, 2020-11-22 at 19:25 +0100, Tommaso Fonda wrote:
> I ran make 4.3 with the --trace option, the result I saw was, for
> example (I have translated the string from Italian to English, thus
> the message is probably not 100% equal to the native English one):
> scripts/Makefile.build:307: updating target «arch/arm/mm/iomap.o»
> because of: FORCE include/generated/bounds.h

Well, a FORCE target is one that is generally provided to (as the name
implies) force the target to rebuild.  This is not built into make but
is a common idiom among makefile authors.

So, the fact that the target rebuilt when FORCE exists is not
surprising.  However, since that's not the only file that has changed
(you say there are other files that appear as updated prerequisites,
not just FORCE) the entire behavior is odd.

Please look through the trace output and see why FORCE was determined
to be out of date, and look for why the given header file was
determined to be out of date.  You have to follow things back to the
very beginning, to know why the rebuild was kicked off.

Although a bisect will be interesting my suspicion is that it may not
be as definitive as we'd like.

The real question is, how is make either behaving or interpreting the
makefile differently between a version that does work and a version
that doesn't work.

--trace was a good first step, but it only shows us why make does
decide to rebuild; it doesn't really tell us much about why make didn't
decide to rebuild (when it behaves the way you want).

To know that we'll need to enable full debugging with "make -d".  That
generates a LOT of output, so there's nothing for it but to redirect it
to a file and sift through it.

If you can reduce your build to just one single file that is not
rebuilt with "working" make and is rebuilt with "not working" make, say
by running "make arch/arm/mm/iomap.o" or similar, it will be much
simpler.

Run "make -d" first with the working make and save that output, then
run "make -d" again with the non-working make and save that output.
 Then see if you can see where the two versions diverge in their
behavior (make different decisions about what is out of date, etc.)