Re: [PATCH] perf: Fix UAPI fallout

[David Howells]

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:

	-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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/