From: Quentin Monnet <quentin@isovalent.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next v2 6/9] bpf: iterators: install libbpf headers when building
Date: Sat, 2 Oct 2021 23:11:48 +0100 [thread overview]
Message-ID: <CACdoK4K4-x4+ZWXyB697Kn8RK5AyoCST+V7Lhtk_Kaqm5uQ6wg@mail.gmail.com> (raw)
In-Reply-To: <CACdoK4LL91u-JK1fZ3XvkrTXsKBVsN-y1Js4QSPkWyS51KPB8Q@mail.gmail.com>
On Sat, 2 Oct 2021 at 21:27, Quentin Monnet <quentin@isovalent.com> wrote:
>
> On Sat, 2 Oct 2021 at 00:20, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> >
> > On Fri, Oct 1, 2021 at 4:09 AM Quentin Monnet <quentin@isovalent.com> wrote:
> > >
> > > API headers from libbpf should not be accessed directly from the
> > > library's source directory. Instead, they should be exported with "make
> > > install_headers". Let's make sure that bpf/preload/iterators/Makefile
> > > installs the headers properly when building.
>
> > >
> > > -$(BPFOBJ): $(wildcard $(LIBBPF_SRC)/*.[ch] $(LIBBPF_SRC)/Makefile) | $(OUTPUT)
> > > +$(BPFOBJ): $(wildcard $(LIBBPF_SRC)/*.[ch] $(LIBBPF_SRC)/Makefile) \
> > > + | $(LIBBPF_OUTPUT) $(LIBBPF_INCLUDE)
> >
> > Would it make sense for libbpf's Makefile to create include and output
> > directories on its own? We wouldn't need to have these order-only
> > dependencies everywhere, right?
>
> Good point, I'll have a look at it.
> Quentin
So libbpf already creates the include (and parent $(DESTDIR))
directory, so I can get rid of the related dependencies. But I don't
see an easy solution for the output directory for the object files.
The issue is that libbpf's Makefile includes
tools/scripts/Makefile.include, which checks $(OUTPUT) and errors out
if the directory does not exist. This prevents us from creating the
directory as part of the regular targets. We could create it
unconditionally before running any target, but it's ugly; and I don't
see any simple workaround.
So I'll remove the deps on $(LIBBPF_INCLUDE) and keep the ones on
$(LIBBPF_OUTPUT).
next prev parent reply other threads:[~2021-10-02 22:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-01 11:08 [PATCH bpf-next v2 0/9] install libbpf headers when using the library Quentin Monnet
2021-10-01 11:08 ` [PATCH bpf-next v2 1/9] tools: bpftool: remove unused includes to <bpf/bpf_gen_internal.h> Quentin Monnet
2021-10-01 11:08 ` [PATCH bpf-next v2 2/9] tools: bpftool: install libbpf headers instead of including the dir Quentin Monnet
2021-10-01 22:55 ` Andrii Nakryiko
2021-10-01 11:08 ` [PATCH bpf-next v2 3/9] tools: resolve_btfids: install libbpf headers when building Quentin Monnet
2021-10-01 23:01 ` Andrii Nakryiko
2021-10-01 11:08 ` [PATCH bpf-next v2 4/9] tools: runqslower: " Quentin Monnet
2021-10-01 11:08 ` [PATCH bpf-next v2 5/9] bpf: preload: " Quentin Monnet
2021-10-01 11:08 ` [PATCH bpf-next v2 6/9] bpf: iterators: " Quentin Monnet
2021-10-01 23:19 ` Andrii Nakryiko
2021-10-02 20:27 ` Quentin Monnet
2021-10-02 22:11 ` Quentin Monnet [this message]
2021-10-04 19:10 ` Andrii Nakryiko
2021-10-04 21:30 ` Quentin Monnet
2021-10-05 20:03 ` Quentin Monnet
2021-10-06 17:44 ` Andrii Nakryiko
2021-10-01 11:08 ` [PATCH bpf-next v2 7/9] samples/bpf: " Quentin Monnet
2021-10-01 23:22 ` Andrii Nakryiko
2021-10-02 20:30 ` Quentin Monnet
2021-10-01 11:08 ` [PATCH bpf-next v2 8/9] samples/bpf: update .gitignore Quentin Monnet
2021-10-01 11:08 ` [PATCH bpf-next v2 9/9] selftests/bpf: better clean up for runqslower in test_bpftool_build.sh Quentin Monnet
2021-10-01 23:05 ` [PATCH bpf-next v2 0/9] install libbpf headers when using the library Andrii Nakryiko
2021-10-01 23:27 ` Andrii Nakryiko
2021-10-02 20:40 ` Quentin Monnet
2021-10-03 19:20 ` Quentin Monnet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACdoK4K4-x4+ZWXyB697Kn8RK5AyoCST+V7Lhtk_Kaqm5uQ6wg@mail.gmail.com \
--to=quentin@isovalent.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).