1

I declared a variable in the make file like this-

var_COVERAGE_FLAGS?=   

I assigned a value to the variable in a target called coverage

coverage:var_COVERAGE_FLAGS = -MDevel::Cover=-silent,on,+select,/home/scratch.ataur_gpu/run_steps/client/dev1/dev/inf/run/mainline/lib,+ignore,^\\w+
coverage:var_COVERAGE_POST=2>&1 | grep -v "Can't";
coverage:var_COVERAGE_PRE = @echo "Running coverage for $@";
coverage:clean_coverage
    $(call run_with_perl,$*) $(var_COVERAGE_FLAGS) $(var_COVERAGE_TEST_NAMES) $(var_COVERAGE_POST)
    @echo "$*"
    @echo "$(var_COVERAGE_FLAGS)"
    @echo "====================="
    $(exec_COVER)

I defined

define run_with_perl
$(PERL_RUNNER) $1 $(TEST_ARGS)
endef

and the Variable PERL_RUNNER is defined as below

PERL_RUNNER                             := $(exec_PERL) $(PERL_ARGS) $(env_PERLINCLUDE) $(var_COVERAGE_FLAGS)

and the rest of the variable are defined properly The issue is whenever I am calling run_with_perl the value of $(var_COVERAGE_FLAGS) is reset to null or you can say that is Target Specific Variable. So how do I Make it a Global Variable??

AddWeb Solution Pvt Ltd
  • 21,025
  • 5
  • 26
  • 57
abhishek taur
  • 53
  • 1
  • 2
  • 7

1 Answers1

1

All variables in make which are not target-specific, are "global". So if you want a global variable you just remove the target part (e.g., coverage:) and set the variable without it.

However, you don't really need to do this. Your problem is that you're using a simple assignment for PERL_RUNNER. That means that the right hand side of the assignment is expanded immediately as the makefile is parsed. That happens outside of any target context so no target-specific value is available.

If you change the assignment of PERL_RUNNER to use = instead of := then your problem will disappear without having to change anything else (use global variables):

PERL_RUNNER = $(exec_PERL) $(PERL_ARGS) $(env_PERLINCLUDE) $(var_COVERAGE_FLAGS)

Now expansion of the left side will be deferred until the variable is used, inside the recipe of coverage where the target-specific variables are in scope.

However, I don't even know why you're adding this here. You already have added this as part of the recipe, which is actually the right way to do it rather than adding things into PERL_RUNNER itself. This recipe line:

$(call run_with_perl,$*) $(var_COVERAGE_FLAGS) $(var_COVERAGE_TEST_NAMES) $(var_COVERAGE_POST)

expands to this:

$(PERL_RUNNER) $* $(TEST_ARGS) $(var_COVERAGE_FLAGS) $(var_COVERAGE_TEST_NAMES) $(var_COVERAGE_POST)

which expands to this:

$(exec_PERL) $(PERL_ARGS) $(env_PERLINCLUDE) $(var_COVERAGE_FLAGS) $* $(TEST_ARGS) $(var_COVERAGE_FLAGS) $(var_COVERAGE_TEST_NAMES) $(var_COVERAGE_POST)

You can see var_COVERAGE_FLAGS is already there. Is it just because the flags are out of order? You can change the order by modifying the arguments to the call function; for example:

$(call run_with_perl,$(var_COVERAGE_FLAGS) $*) $(var_COVERAGE_TEST_NAMES) $(var_COVERAGE_POST)

will put things in the right order and this is a much better solution than trying to add target-specific flags to a generic variable like PERL_RUNNER; what if you wanted to use PERL_RUNNER in some other target in addition to the coverage target?

bobbogo
  • 14,989
  • 3
  • 48
  • 57
MadScientist
  • 92,819
  • 9
  • 109
  • 136