Search code examples
unixmakefilehp-ux

Error in calling one make target from another


$make --- Will have normal build

$make CAdvisor Above will do following steps:

1) Update variable CC, now it should become "cadvise -pdb mypdb +wlint +wall aCC"

2) Run all with updated CC option

CC = aCC
CFLAGS  = -c #-Wall
LDFLAGS =
SOURCES = foo.cc
OBJECTS = $(SOURCES:.cc=.o)
EXECUTABLE = observer
RM=rm -rf
CADVISE_OPTS= -pdb mypdb +wlint
CADVISE= /opt/cadvise/bin/cadvise

.PHONY : CAdvisor update_cc clean all

all: $(SOURCES) $(EXECUTABLE)
$(EXECUTABLE): $(OBJECTS)
    $(CC) $(LDFLAGS) $(OBJECTS) -o $@
.cc.o:
    $(CC) $(CFLAGS) $< -o $@

clean:
    $(RM) $(EXECUTABLE) $(OBJECTS)

update_cc: CC := ${$(CADVISE) $(CADVISE_OPTS) $(CC)}

CAdvisor: update_cc all;
    @echo DEBD $(CC)

Now above code is giving me error:

**$ make CAdvisor
Make: Don't know how to make CC.  Stop.
$**

Thanks


Solution

  • Sorry, but that's not how target-specific variables work. Target-specific variables are scoped to their target and any prerequisite built as a result of building that target. It's not the case that the target-specific setting changes the value of the global variable for the rest of the recipes expanded by make.

    In your example, all is not a prerequisite of update_cc, it's a sibling. So, target-specific variables that are set for update_cc have no impact on the all target.

    Second, using ${$(CADVISE) $(CADVISE_OPTS) $(CC)} is definitely not right: the inside will be expanded first then because the entire thing is enclosed in ${...} it will be treated as a variable name, and that variable (which clearly doesn't exist) will be looked up, resulting in an empty string.

    I don't know why you have added the extra target update_cc at all; why not just set the target-specific variable on the CAdvisor target?

    CAdvisor: CC := $(CADVISE) $(CADVISE_OPTS) $(CC)
    
    CAdvisor: all
            @echo DEBD $(CC)