Re: [PATCH 3/3] x86/build: Clean up boot/Makefile

[Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>]

On 14/04/2022 18:45, Anthony PERARD wrote:
> On Thu, Apr 14, 2022 at 12:47:08PM +0100, Andrew Cooper wrote:
>> There are no .S intermediate files, so rework in terms of head-bin-objs.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> The patch looks fine.
>
> Reviewed-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>
>> ---
>> I'm slightly -1 on this, because
>>
>>   head-bin-objs := $(addprefix $(obj)/,$(head-bin-objs))
>>
>> is substantial obfuscation which I'd prefer to bin.
> It might be possible to do something that Kbuild does, which would be to
> teach the build system to look for "$(head-objs)" or maybe
> "$(head-bin-objs)" when it want to build "head.o". That something that's
> done in Kbuild I think to build a module from several source files.
>
>> Anthony: Why does dropping the targets += line interfere with incremental
>> builds?  With it gone, *.bin are regenerated unconditionally, but I can't see
>> what would cause that, nor why the normal dependencies on head.o don't work.
> Try to build with "make V=2", make will display why a target is been
> rebuild (when this target is built with $(if_changed, )
>
> $(targets) is used by Rules.mk to findout which dependencies files (the
> .cmd) to load and only load them if the target exist. Then the
> $(if_changed, ) macro rerun the command if prereq are newer than the
> target or if the command as changed. Without the .cmd file loaded, the
> macro would compare the new command to an empty value and so rebuild the
> target.
>
> Now, the *.bin files are regenerated because cmdline.o is been rebuild
> mostly because make didn't load the record of the previous command run.

I'm not certain if this case is a match with Linux's module logic.  The
module logic is "compile each .c file, then link all the .o's together
into one .ko".

In this case, we're saying "to assemble head.S to head.o, you first need
to build {cmdline,reloc}.bin so the incbin doesn't explode".  I guess it
depends how generic the "$X depends on arbitrary $Y's" expression can be
made.

Between this patch an the previous one, I've clearly got mixed up with
what exactly the target+= and regular dependencies.

The comment specifically refers to the fact that the old #include
"cmdline.S" used to show up as a dep in .head.o.cmd, whereas .incbin
doesn't.  (Not surprising, because -M and friends are from the
preprocessor, not assembler, but it would be helpful if this limitation
didn't exist.)  As a consequence, the dependency needs adding back in
somehow.

From your description above, I assume that simply being listed as a dep
isn't good enough to trigger a recursive load of the .bin's .cmd file
(not that there is one), which is why they need adding specially to targets?

As I have simplified this to (almost) normal build runes, should we be
expressing it differently now to fit in with the new way of doing things?

~Andrew