Re: [PATCH 1/3] tools: fix off-by 1 relative directory includes

Ian Rogers
2020-03-06T16:48:05Z

On Fri, Mar 6, 2020 at 1:34 AM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Thu, Mar 05, 2020 at 11:11:08PM -0800, Ian Rogers wrote:
> > This is currently working due to extra include paths in the build.
>
> if you're fixing this, why not remove that extra include path then?

TL;DR it is complicated, but the include paths are all currently
necessary I believe and doing this way is necessary due to how header
files may be copied out of the kernel.

The current build uses multiple -Is to ensure the correct version of a
file is included, for example there are 27 files called bitops.h and
29 called bitsperlong.h. In
Google we're using libraries and bazel build files:
https://docs.bazel.build/versions/master/be/c-cpp.html#cc_library
and there's no way to say if you depend on this library then you need
this include path. We've tried to make perf this way but having tied
ourselves in knots we decided instead to emulate the include path
behaviour by rewriting includes when we import code using copybara:
https://github.com/google/copybara
We are able when doing this to prioritize the include paths we rewrite
so that a local directory version of a header is preferred over say
one in tools/lib/perf and perhaps tools/perf. Having full include
paths isn't really an option upstream as the same header file may be
copied into a libc project that has a different directory layout.
As we have absolute include paths at the time of building we need
relative include paths to be correct. Upstream -Is allow the build to
find the file but it is a bit of a quirk of the C preprocessor, so
fixing these off-by 1s feels like value add both for us and upstream.
For upstream to do anything different I think is going to be a
significant rewrite of how the Makefile build works and I'm not sure
what the result would look like.

Thanks!
Ian

> jirka
>