Em Mon, Jan 04, 2021 at 10:17:36PM +0000, Luca Boccassi escreveu: > On Mon, 2021-01-04 at 12:23 -0800, Andrii Nakryiko wrote: > > On Sun, Jan 3, 2021 at 1:30 PM Luca Boccassi <bluca@xxxxxxxxxx> > > > > > #include "dutil.h" > > > > > +#ifdef LIBBPF_FOUND > > > > > +#include <bpf/libbpf.h> > > > > > +#else > > > > > #include "lib/bpf/src/libbpf.h" > > > > > +#endif > > > > this is horrible, are you sure there is no way to make > > > > <bpf/libbpf.h> > > > > work for both cases? > > > It really is, but unfortunately I don't see other ways that are > > > not just as horrible. Suggestions welcome. The only thing I can > > > think of, is if libbpf used the same directory hierarchy in-tree > > > as it does in the installed tree. Ie: move those headers from > > > libbpf/src/foo.h to libbpf/include/bpf/foo.h. Then we would just > > > have the - Ilib/bpf/include in CPPFLAGS for the embedded build > > > defined in the CMake files, and the sources would only use the > > > "system" includes everywhere, without ifdeffery. > > > Given you maintain libbpf, would that be something you'd accept? > > > It's quite a common pattern for libraries to store their public > > > headers in a separate directory in the git tree, after all. > > It's quite risky, as there are plenty of (sometimes private) > > integrations that assume such a layout of libbpf, so we'll be > > breaking them badly. Makefile-based projects do `make > > install_headers` to put *only exported* headers into the desired > > location. I'm not sure what's the best way to achieve the same with > > Cmake, though. > > One quick and easy hack would be to put a symlink lib/include/bpf -> > > lib/bpf/src into pahole repo. And add -Ilib/include to let compiler > > handle <bpf/*.h> properly. > Sure, that works for me if it's acceptable as a solution. Sent v3 that > implements it. Thanks for the suggestion. Andrii, can I have your Reviewed-by or Acked-by for v3? I have it in my local repo and will push publicly later today after I perform tests. - Arnaldo
