Re: [PATCH bpf-next v2 6/9] bpf: iterators: install libbpf headers when building

On Sat, Oct 2, 2021 at 3:12 PM Quentin Monnet [off-list ref] wrote:

On Sat, 2 Oct 2021 at 21:27, Quentin Monnet [off-list ref] wrote:

quoted

On Sat, 2 Oct 2021 at 00:20, Andrii Nakryiko [off-list ref] wrote:

quoted

On Fri, Oct 1, 2021 at 4:09 AM Quentin Monnet [off-list ref] wrote:

quoted

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.

quoted

quoted

-$(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

Did you check what benefits the use of tools/scripts/Makefile.include
brings? Last time I had to deal with some non-trivial Makefile
problem, this extra dance with tools/scripts/Makefile.include and some
related complexities didn't seem very justified. So unless there are
some very big benefits to having tool's Makefile.include included, I'd
rather simplify libbpf's in-kernel Makefile and make it more
straightforward. We have a completely independent separate Makefile
for libbpf in Github, and I think it's more straightforward. Doesn't
have to be done in this change, of course, but I was curious to hear
your thoughts given you seem to have spent tons of time on this
already.

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).