Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH] perf: Fix UAPI fallout | Date | Fri, 19 Oct 2012 14:35:37 +0100 |
| |
Ingo Molnar <mingo@kernel.org> 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:
-BASIC_CFLAGS = -Iutil/include -Iarch/$(ARCH)/include -I$(OUTPUT)util -I$(TRACE_EVENT_DIR) -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE +$(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?
David
| |