Re: [PATCH] perf: Fix UAPI fallout

From: David Howells
Date: Fri Oct 19 2012 - 09:36:06 EST

Ingo Molnar <mingo@xxxxxxxxxx> wrote:

> What we want in .c files are not ../.. inclusions but the
> 'seemless' <linux/abc.h> inclusions. Which is the overwhelming
> majority, gladly. Do we want to make that the 100% majority?

I think this is going to be necessary for when x86 gets merged. x86's
asm/unistd.h #includes uapi/asm/unistd.h, so you can't manually specify the
header without also specifying a -I flag.

I've been having a prod at it, and this seems to partially work:

+$(info XXX $(srctree))
+BASIC_CFLAGS = -Iutil/include -Iarch/$(ARCH)/include -I../../arch/$(ARCH)/include -I$(OUTPUT)util -I$(TRACE_EVENT_DIR) -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE

However, I'm trying to work out what will happen if this is run in a separate
output dir, but if I do:

make tools/perf O=build_dir

from the bottom directory, I get:

scripts/Makefile.include:2: *** O=build_dir does not exist. Stop.

The problem is that the bottom-level Makefile does this:

tools/: FORCE
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS= -C $(src)/tools/
tools/%: FORCE
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS= -C $(src)/tools/ $*

which changes the directory, rendering a relative O= that would be good for
building the normal kernel useless for building a tool. Should these rules
respecify the O= flag here, or should we give an error if someone tries it?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at