Message ID | 157909756858.1192265.6657542187065456112.stgit@toke.dk (mailing list archive) |
---|---|
Headers | show |
Series | tools: Use consistent libbpf include paths everywhere | expand |
On Wed, Jan 15, 2020 at 6:13 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote: > > The recent commit 6910d7d3867a ("selftests/bpf: Ensure bpf_helper_defs.h are > taken from selftests dir") broke compilation against libbpf if it is installed > on the system, and $INCLUDEDIR/bpf is not in the include path. > > Since having the bpf/ subdir of $INCLUDEDIR in the include path has never been a > requirement for building against libbpf before, this needs to be fixed. One > option is to just revert the offending commit and figure out a different way to > achieve what it aims for. However, this series takes a different approach: > Changing all in-tree users of libbpf to consistently use a bpf/ prefix in > #include directives for header files from libbpf. > > This turns out to be a somewhat invasive change in the number of files touched; > however, the actual changes to files are fairly trivial (most of them are simply > made with 'sed'). Also, this approach has the advantage that it makes external > and internal users consistent with each other, and ensures no future changes > breaks things in the same way as the commit referenced above. > > The series is split to make the change for one tool subdir at a time, while > trying not to break the build along the way. It is structured like this: > > - Patch 1-2: Trivial fixes to Makefiles for issues I discovered while changing > the include paths. > > - Patch 3-7: Change the include directives to use the bpf/ prefix, and updates > Makefiles to make sure tools/lib/ is part of the include path, but without > removing tools/lib/bpf > > - Patch 8: Change the bpf_helpers file in libbpf itself to use the bpf/ prefix > when including (the original source of breakage). > > - Patch 9-10: Remove tools/lib/bpf from include paths to make sure we don't > inadvertently re-introduce includes without the bpf/ prefix. > > --- Thanks, Toke, for this clean up! I tested it locally for my set up: runqslower, bpftool, libbpf, and selftests all build fine, so it looks good. My only concern is with selftests/bpf Makefile, we shouldn't build anything outside of selftests/bpf. Let's fix that. Thanks! > > Toke Høiland-Jørgensen (10): > samples/bpf: Don't try to remove user's homedir on clean > tools/bpf/runqslower: Fix override option for VMLINUX_BTF > tools/runqslower: Use consistent include paths for libbpf > selftests: Use consistent include paths for libbpf > bpftool: Use consistent include paths for libbpf > perf: Use consistent include paths for libbpf > samples/bpf: Use consistent include paths for libbpf > libbpf: Fix include of bpf_helpers.h when libbpf is installed on system > selftests: Remove tools/lib/bpf from include path > tools/runqslower: Remove tools/lib/bpf from include path > > [...]
On Wed, Jan 15, 2020 at 03:12:48PM +0100, Toke Høiland-Jørgensen wrote: > The recent commit 6910d7d3867a ("selftests/bpf: Ensure bpf_helper_defs.h are > taken from selftests dir") broke compilation against libbpf if it is installed > on the system, and $INCLUDEDIR/bpf is not in the include path. > > Since having the bpf/ subdir of $INCLUDEDIR in the include path has never been a > requirement for building against libbpf before, this needs to be fixed. One > option is to just revert the offending commit and figure out a different way to > achieve what it aims for. However, this series takes a different approach: > Changing all in-tree users of libbpf to consistently use a bpf/ prefix in > #include directives for header files from libbpf. I don't think such approach will work in all cases. Consider the user installing libbpf headers into /home/somebody/include/bpf/, passing that path to -I and trying to build bpf progs that do #include "bpf_helpers.h"... In the current shape of libbpf everything will compile fine, but after patch 8 of this series the compiler will not find bpf/bpf_helper_defs.h. So I think we have no choice, but to revert that part of Andrii's patch. Note that doing #include "" for additional library headers is a common practice. There was nothing wrong about #include "bpf_helper_defs.h" in bpf_helpers.h.
Alexei Starovoitov <alexei.starovoitov@gmail.com> writes: > On Wed, Jan 15, 2020 at 03:12:48PM +0100, Toke Høiland-Jørgensen wrote: >> The recent commit 6910d7d3867a ("selftests/bpf: Ensure bpf_helper_defs.h are >> taken from selftests dir") broke compilation against libbpf if it is installed >> on the system, and $INCLUDEDIR/bpf is not in the include path. >> >> Since having the bpf/ subdir of $INCLUDEDIR in the include path has never been a >> requirement for building against libbpf before, this needs to be fixed. One >> option is to just revert the offending commit and figure out a different way to >> achieve what it aims for. However, this series takes a different approach: >> Changing all in-tree users of libbpf to consistently use a bpf/ prefix in >> #include directives for header files from libbpf. > > I don't think such approach will work in all cases. > Consider the user installing libbpf headers into /home/somebody/include/bpf/, > passing that path to -I and trying to build bpf progs > that do #include "bpf_helpers.h"... > In the current shape of libbpf everything will compile fine, > but after patch 8 of this series the compiler will not find bpf/bpf_helper_defs.h. > So I think we have no choice, but to revert that part of Andrii's patch. > Note that doing #include "" for additional library headers is a common practice. > There was nothing wrong about #include "bpf_helper_defs.h" in bpf_helpers.h. OK, I'll take another look at that bit and see if I can get it to work with #include "bpf_helper_defs.h" and still function with the read-only tree (and avoid stale headers). -Toke
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes: > On Wed, Jan 15, 2020 at 6:13 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote: >> >> The recent commit 6910d7d3867a ("selftests/bpf: Ensure bpf_helper_defs.h are >> taken from selftests dir") broke compilation against libbpf if it is installed >> on the system, and $INCLUDEDIR/bpf is not in the include path. >> >> Since having the bpf/ subdir of $INCLUDEDIR in the include path has never been a >> requirement for building against libbpf before, this needs to be fixed. One >> option is to just revert the offending commit and figure out a different way to >> achieve what it aims for. However, this series takes a different approach: >> Changing all in-tree users of libbpf to consistently use a bpf/ prefix in >> #include directives for header files from libbpf. >> >> This turns out to be a somewhat invasive change in the number of files touched; >> however, the actual changes to files are fairly trivial (most of them are simply >> made with 'sed'). Also, this approach has the advantage that it makes external >> and internal users consistent with each other, and ensures no future changes >> breaks things in the same way as the commit referenced above. >> >> The series is split to make the change for one tool subdir at a time, while >> trying not to break the build along the way. It is structured like this: >> >> - Patch 1-2: Trivial fixes to Makefiles for issues I discovered while changing >> the include paths. >> >> - Patch 3-7: Change the include directives to use the bpf/ prefix, and updates >> Makefiles to make sure tools/lib/ is part of the include path, but without >> removing tools/lib/bpf >> >> - Patch 8: Change the bpf_helpers file in libbpf itself to use the bpf/ prefix >> when including (the original source of breakage). >> >> - Patch 9-10: Remove tools/lib/bpf from include paths to make sure we don't >> inadvertently re-introduce includes without the bpf/ prefix. >> >> --- > > Thanks, Toke, for this clean up! I tested it locally for my set up: > runqslower, bpftool, libbpf, and selftests all build fine, so it looks > good. My only concern is with selftests/bpf Makefile, we shouldn't > build anything outside of selftests/bpf. Let's fix that. Thanks! Great, thanks for testing! I'll fix up your comments (and Alexei's) and submit another version tomorrow. -Toke