On Thu, Feb 4, 2021 at 1:21 PM Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > We want this clean to be called from tree's root Makefile, > which defines same srctree variable and that will screw > the make setup. > > We actually do not use srctree being passed from outside, > so we can solve this by setting current srctree value > directly. > > Also root Makefile does not define the implicit RM variable, > so adding RM initialization. > > Signed-off-by: Jiri Olsa <jolsa@xxxxxxxxxx> > --- > tools/bpf/resolve_btfids/Makefile | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/tools/bpf/resolve_btfids/Makefile b/tools/bpf/resolve_btfids/Makefile > index 3007cfabf5e6..b41fc9a81e83 100644 > --- a/tools/bpf/resolve_btfids/Makefile > +++ b/tools/bpf/resolve_btfids/Makefile > @@ -2,11 +2,9 @@ > include ../../scripts/Makefile.include > include ../../scripts/Makefile.arch > > -ifeq ($(srctree),) > srctree := $(patsubst %/,%,$(dir $(CURDIR))) > srctree := $(patsubst %/,%,$(dir $(srctree))) > srctree := $(patsubst %/,%,$(dir $(srctree))) Is this just a weird way of doing $(abspath $(CURDIR)/../../../)? Are there any advantages compared to a more straightforward way? > -endif > > ifeq ($(V),1) > Q = > @@ -22,6 +20,7 @@ AR = $(HOSTAR) > CC = $(HOSTCC) > LD = $(HOSTLD) > ARCH = $(HOSTARCH) > +RM ?= rm > > OUTPUT ?= $(srctree)/tools/bpf/resolve_btfids/ > > -- > 2.26.2 >
