[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: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH v2 02/47] trace: switch io/ directory to modular trace.h file
Date: Wed, 11 Jan 2017 17:40:45 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

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

> > 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".

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

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

reply via email to

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