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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.01.2023 12:02, Andrew Cooper wrote:
> On 12/01/2023 7:46 am, Jan Beulich wrote:
>> On 11.01.2023 23:29, Andrew Cooper wrote:
>>> For posterity,
>>> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/3585379553 is
>>> the issue in question.
>>>
>>> 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.
> 
> So I had concluded (wrongly) that it was to do with an asymmetry of
> include paths, but it's not.  <../$x> would behave the same, even if it
> is a bit more obviously wrong.
> 
> The actual problem is the use of ./ or ../ because, despite how they
> read, they are never relative to the current file.  The contents between
> the "" or <> is treated as a string literal and not interpreted by CPP.

First of all the C spec says nothing about how searching is performed.
It's all implementation defined.

Gcc documentation in turn is quite explicit: "By default, the
preprocessor looks for header files included by the quote form of the
directive #include "file" first relative to the directory of the
current file, and then ..." This is behavior I know from all compilers
I've ever worked with, so while not part of the C standard it is
(hopefully) something we can rely upon (or specify as a requirement
for people wanting to use the headers unmodified).

So I agree using ../ inside angle backets would be bogus at best, but
I think using such inside double quotes is sufficient generically okay.
Hence ...

> So furthermore, the public headers are buggy in their use of ../ because
> it is an implicit dependency on -I/path/to/xen/headers/dir/ being
> earlier on the include path than other dirs with these fairly generic
> and not-xen-prefixed file names.

... I don't see any bugginess here.

Jan