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

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

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.

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.

Thanks,
Ian.