Re: [Multiple reverts] [RFC PATCH] build: include/compat: figure out which other compat headers are needed

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Thu, Jan 12, 2023 at 08:46:23AM +0100, Jan Beulich wrote:
> On 11.01.2023 23:29, Andrew Cooper wrote:
> > In file included from arch/x86/hvm/hvm.c:82:
> > ./include/compat/hvm/hvm_op.h:6:10: fatal error: ../trace.h: No such
> > file or directory
> >     6 | #include "../trace.h"
> >       |          ^~~~~~~~~~~~
> > compilation terminated.
> > make[4]: *** [Rules.mk:246: arch/x86/hvm/hvm.o] Error 1
> > make[3]: *** [Rules.mk:320: arch/x86/hvm] Error 2
> > make[3]: *** Waiting for unfinished jobs....
> > 
> > 
> > All public headers use "../" relative includes for traversing the
> > public/ hierarchy.  This cannot feasibly change given our "copy this
> > into your project" stance, but it means the compat headers have the same
> > structure under compat/.
> > 
> > This include is supposed to be including compat/trace.h but it was
> > actually picking up x86's asm/trace.h, hence the build failure now that
> > I've deleted the file.
> > 
> > This demonstrates that trying to be clever with -iquote is a mistake. 
> > Nothing good can possibly come of having the <> and "" include paths
> > being different.  Therefore we must revert all uses of -iquote.
> 
> I'm afraid I can't see the connection between use of -iquote and the bug
> here.

Me neither, -iquote isn't used on that object's command line.

> > But, that isn't the only bug.
> > 
> > The real hvm_op.h legitimately includes the real trace.h, therefore the
> > compat hvm_op.h legitimately includes the compat trace.h too.  But
> > generation of compat trace.h was made asymmetric because of 2c8fabb223.
> > 
> > In hindsight, that's a public ABI breakage.  The current configuration
> > of this build of the hypervisor has no legitimate bearing on the headers
> > needing to be installed to /usr/include/xen.
> > 
> > Or put another way, it is a breakage to require Xen to have
> > CONFIG_COMPAT+CONFIG_TRACEBUFFER enabled in the build simply to get the
> > public API headers generated properly.
> 
> There are no public API headers which are generated. The compat headers
> are generate solely for Xen's internal purposes (and hence there's also
> no public ABI breakage). Since generation is slow, avoiding to generate
> ones not needed during the build is helpful.

If only we could do the generation faster:
    
https://lore.kernel.org/xen-devel/20220614162248.40278-5-anthony.perard@xxxxxxxxxx/
    patch which takes care of the slower part of the generation (slower
    at least for some compat headers).

Cheers,

-- 
Anthony PERARD