Ingo Molnar <mi...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
