Re: [PATCH] build: fix dependency tracking for preprocessed files

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.06.2020 13:35, Andrew Cooper wrote:
> On 04/06/2020 11:22, Jan Beulich wrote:
>> While the issue is more general, I noticed that asm-macros.i not getting
>> re-generated as needed. This was due to its .*.d file mentioning
>> asm-macros.o instead of asm-macros.i. Use -MQ here as well, and while at
>> it also use -MQ to avoid the somewhat fragile sed-ary on the *.lds
>> dependency tracking files. While there, further avoid open-coding $(CPP)
>> and drop the bogus -Ui386.
> 
> Its not bogus.  It really is needed to prevent OUTPUT_ARCH(i386:x86-64)
> being preprocessed to OUTPUT_ARCH(1:x86-64)
> 
> This explodes properly with 32bit builds, but we might get away with it
> now on a 64bit build (preprocessing without -m32 does appear to skip
> this transformation).

We haven't been doing 32-bit builds for quite a while, hence I continue
to assert the -U option is bogus; I'm not claiming it always has been
(that's true just for Arm).

> However, the robust way to deal with it is:
> 
> /* Don't clobber the ld directive */
> #undef i386
> 
> unconditionally in xen.lds.S

This would mean to add code with no effect, which I'd prefer to avoid.

>> --- a/xen/Rules.mk
>> +++ b/xen/Rules.mk
>> @@ -201,13 +201,13 @@ $(filter %.init.o,$(obj-y) $(obj-bin-y)
>>      $(call if_changed,obj_init_o)
>>  
>>  quiet_cmd_cpp_i_c = CPP     $@
>> -cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@
>> +cmd_cpp_i_c = $(CPP) $(filter-out -Wa$(comma)%,$(c_flags)) $< -o $@ -MQ $@
> 
> Please can -MQ come before $<, so the input and output files are still
> at the end of the command.  It is a very useful property of the current
> setup, when playing build system surgery.

Ah yes, but then I'll make it " -MQ $@ -o $@ $<", better matching the
.lds rules (where I'll also move -MQ ahead of -o).

> If you're happy with both of these suggestions, Reviewed-by: Andrew
> Cooper <andrew.cooper3@xxxxxxxxxx> to save another round trip.

As per above, only the latter, so for now I won't put it into the
patch.

> Alternatively, I'm happy to submit the i386 as a prereq patch, seeing as
> it isn't now such a trivial change any more.

As per above, I don't think such an adjustment is wanted or needed.

Jan