[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 02/47] trace: switch io/ directory to modular

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v2 02/47] trace: switch io/ directory to modular trace.h file
Date: Wed, 11 Jan 2017 19:05:00 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1

On 11/01/2017 18:40, Daniel P. Berrange wrote:
> On Wed, Jan 11, 2017 at 06:34:40PM +0100, Paolo Bonzini wrote:
>> On 11/01/2017 18:16, Daniel P. Berrange wrote:
>>> I've been trying to get such relative includes to work most of today
>>> and not having much luck. The problem is that while it works in 95%
>>> of the time, there are some source files and header files which need
>>> to include trace.h files not in their local directory
>> Which are they?  I wouldn't have expected that to happen.
> It is indirect - particularly Xen - include/hw/xen/xen_common.h hsa
> some trace points and that is included from many different source
> files. Likewise with include/exec/cpu_ldst_template.h

I see.  Yeah, this gets tricky for template-style headers.  (In the case
of include/hw/xen/xen_common.h I would just move the functions to a .c
file, but that's a separate thing and the template-style headers are a
real problem).

>>> and we can't
>>> use relative includes for that, since the relative include gets
>>> resolved wrt the source file doing the #include, but the trace.h
>>> file is in $BUILD_DIR.
>> Why would #include "../foo/trace.h" be resolved against the source
>> file's path only, and not against all -I directories?
> If we have a plain "../trace.h", then it can end up hitting the
> wrong file, because there are many -I dirs listed and most of
> them contain a trace.h file, so if it matches on the 2nd -I
> dir and you need the one from the 3rd -I dir it gets "fun".

Hmm, I would have expected only the .o directory to have a ../trace.h.
But again it doesn't help for template-style headers where ../trace.h is
resolved according to the including file, not the included file.

A weird idea: what about doing


and then having

     #include GENERATED_TRACE_H

in include/trace.h?

Then you can use full include path for special cases such as
include/hw/xen/xen_common.h, but the common case is handled directly
with just

     #include "trace.h"

which refers to $(srcdir)/include/trace.h? (Take the above with a grain
of salt because I haven't reviewed the patches closely).


> Having all the trace.h files included with path from the root
> is alot simpler to understand IMHO than just plain "trace.h"
> and hoping the -I order is going to ensure the right one is
> found

reply via email to

[Prev in Thread] Current Thread [Next in Thread]