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
