Messages in this thread | | | From | Ian Rogers <> | Date | Fri, 6 Mar 2020 08:47:51 -0800 | Subject | Re: [PATCH 1/3] tools: fix off-by 1 relative directory includes |
| |
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 >
| |