Re: [PATCH 1/2][4.15?] tools/x86: don't rebuild cpuid-autogen.h every time

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.03.2021 12:08, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 1/2][4.15?] tools/x86: don't rebuild 
> cpuid-autogen.h every time"):
>> On 08.03.2021 10:59, Ian Jackson wrote:
>>> Jan Beulich writes ("[PATCH 1/2][4.15?] tools/x86: don't rebuild 
>>> cpuid-autogen.h every time"):
>>>> +# Arrange for preserving of auto-generated headers (to avoid them getting
>>>> +# rebuilt every time): Move the entire xen/lib/x86/ to a temporary place.
>>>> +prep-$(CONFIG_X86):
>>>> +  rm -rf .xen-lib-x86
>>>> +  test ! -d xen/lib/x86 || mv xen/lib/x86 .xen-lib-x86
>>>> +
>>>>  all-$(CONFIG_X86): xen-dir
>>>> +  $(if $(wildcard .xen-lib-x86/*autogen.h),mv .xen-lib-x86/*autogen.h 
>>>> xen/lib/x86/)
>>>> +  rm -rf .xen-lib-x86
>>>>    $(MAKE) -C xen/lib/x86 all XEN_ROOT=$(XEN_ROOT) PYTHON=$(PYTHON)
>>>
>>> Isn't there some better way of doing this ?  I am very wary of adding
>>> additional on-disk Makefile-managed state to a Makefile which is
>>> already going wrong.  I haven't thought about this in enough detail to
>>> identify a specific bug but I think convincing myself that it is
>>> definitely correct is nontrivial.
>>>
>>> Perhaps we could do the removal with a find rune instead, so we can
>>> just skip the files we wanted to keep ?
>>
>> Maybe, and I did consider the option, but it would have felt more
>> fragile to me than this dedicated keep-just-the-few-files approach.
>> The problems we've had with this symlinking don't make me confident
>> in leaving around parts of this subtree; populating from scratch
>> seems like the most robust model (short of the suggested but never
>> carried out removal of the symlinking) to me.
> 
> I'm confused by your reply.
> 
> You aren't confident "leaving around parts of this subtree" but you
> are happy to move it aside and put it back, which seems equivalent.  I
> don't understand why you think the latter would be more reliable.

I move a subdir aside and then move certain files out of it back.
This doesn't leave much uncertainty as to whether other (symlinked)
files / dirs may mistakenly also left around.

> It seems to me that a find rune which deletes individual files can be
> at least as specific as your current wildcard and mv approach.

Possibly, but it may end up being more complex: We want to only
retain files of specific names from a single dir. I don't think
this is as straightforward to express in a find rune. Of course
I'll be fine whichever way the bug gets fixed, but I'm afraid I
don't feel convinced I want to put time into trying the alternative
you suggest. If otoh you wanted to try out yours and it turned out
equivalent or better, I wouldn't mind at all.

Jan