On Tuesday, July 16th, 2024 at 4:21 PM, Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: [...] > The catch-all clause in the current makefile looks as follows: > > $(TRUNNER_BPF_OBJS): $(TRUNNER_OUTPUT)/%.bpf.o: \ > $(TRUNNER_BPF_PROGS_DIR)/%.c \ > $(TRUNNER_BPF_PROGS_DIR)/*.h \ > ... > > This makes all .bpf.o files dependent on all BPF .c files. > .bpf.o files rebuild is the main time consumer, at-least for me. I might be nit-picking, but just so it's clear this target makes each individual %.bpf.o dependent on corresponding progs/%.c, and also on all the headers (because of *.h). I don't think we can easily remove/replace the $(TRUNNER_BPF_OBJS) target, as it also defines a compilation recipe for .bpf.o files. > > I think that simply replacing this catch all by something like: > > $(OUTPUT)/$(TRUNNER_BINARY): $(TRUNNER_BPF_OBJS) > Using a catch-all dependency (each %.test.o depends on *all* .bpf.o) is the current state of the Makefile, without the auto-dependencies patch: $(TRUNNER_TEST_OBJS): $(TRUNNER_OUTPUT)/%.test.o: \ $(TRUNNER_TESTS_DIR)/%.c \ $(TRUNNER_EXTRA_HDRS) \ $(TRUNNER_BPF_OBJS) \ # this line $(TRUNNER_BPF_SKELS) \ ... In the v3 of the patch this dependency simply moved, such that each %.test.d file depends on *all* %.bpf.o, so essentially nothing changed there. So what we've been discussing so far is whether it's worth spending effort on removing/replacing this dependency, and how. Eduard's point about simplification of test cases seems reasonable. However it looks to me that whatever way of handling direct .bpf.o dependencies we might agree on, it would lead to an independent patch series. And settling on catch-all solution (even "for now") means settling on v3 of the patch.
