MAKEPP_VARIABLES(1) Makepp MAKEPP_VARIABLES(1)NAMEmakepp_variables-- How to use variables in makepp
DESCRIPTION
?: $*,
$+,
$/,
$<,
$?,
$@,
$^,
=,
!=,
&=,
+=,
:=,
;=,
?=, A: AR,
ARFLAGS,
AS, C: CC,
CFLAGS,
"changed_dependencies",
changed_inputs,
CURDIR,
CXX,
CXXFLAGS, D: "dependencies",
"dependency", F: F77,
FC,
"foreach", I: input,
inputs, L: LD,
LEX,
LIBTOOL, M: MAKE,
MAKECMDGOALS,
MAKEFLAGS,
MAKEINFO,
MAKEPPFLAGS,
_MAKEPPFLAGS,
MAKEPP_LN_CP,
"makepp_percent_subdirs",
"makepp_require_phony",
"makepp_simple_concatenation",
MAKEPP_VERSION, O: "output",
"outputs", P: PWD, R: RM,
ROOT, S: SHELL,
"sorted_dependencies",
sorted_inputs,
"stem", T: target,
targets, V: VPATH, Y: YACC
Makefiles typically use variables in many places. One important reason
for using variables is to ensure that information is contained in only
one place in the makefile, so that if it changes, there is no danger of
the two copies of the information getting out of sync.
Variable names are case sensitive. In theory, variable names can be
made of many characters, but makepp will probably not be able to grok
it if you do anything other than alphanumeric characters, "_", and "-".
Each makefile has its own set of variables, and setting a variable in
one makefile will have no effect on its value in any other makefile.
If you want to have variables set in many makefiles, the best way to do
it is to have each of them include a common definitions file (see the
include statement) or use "global" variables.
Variable Assignment
A variable can assume a value in several different ways:
· A variable may be set inside a makefile. There are a number of
different ways to do this; see below.
· A variable's value may be specified on the command line, like this:
makepp CFLAGS=-O2 my_program
If more than one makefile is loaded, the CFLAGS variable is
propagated to all of the makefiles. Variables set on the command
line automatically override any setting of the variable in any of
the makefiles.
If ever needed, the makefile must in turn explicitly override
command line settings. The intention is not to ignore what the
user requests, but rather a way to modify it. The "override"
modifier may precede any assignment statement. But in the case of
keyword statements, the order is important, which is why the
override variant is always shown below. The "override" modifier
applies only to any assignments where it is present, and does not
influence later assignments to the variable.
· If a variable is set in the environment, it can be referenced as a
makepp variable. Ordinarily assignments to variables inside a
makefile override settings from the environment, but you can change
this by using the "-e" or "--environment-overrides" command line
option.
Variables are assigned with one of several assignment expressions, like
this
X = 1
MODULES := a b c d
CC ?= gcc
CFLAGS += -Wall
define VAR
var line 1
var line 2
enddef
export PATH := $(PWD):$(PATH)
global MYPROJECT.INFO = info to be seen in all makefiles
Leading and trailing whitespace around values is always stripped off.
The different assignment operators have somewhat different meanings.
Simple assignment operators
=
VARIABLE = text string
override VARIABLE = text string
This is the usual assignment statement that all implementations of
make support. The expression on the right hand side is not
evaluated until the value of "$(VARIABLE)" is actually used
somewhere. Thus, if you do the following:
X = 1
Y = $(X)
X = 2
Then "$(Y)" later in the makefile will evaluate to "2".
In general, you usually want to use ":=" (see below) instead of "="
because it provides more predictable variable evaluation. However,
there are times when you need to defer the variable evaluation.
Also, if you're writing a makefile that must be backwards-
compatible with some version of make other than GNU make, then you
have no choice: you may only use "=".
:=
VARIABLE := expr
override VARIABLE := expr
This is the same as "VARIABLE = expr" except that the right hand
side is evaluated once and for all at the time of the assignment.
Thus if
X := 1
Y := $(X)
X := 2
then "$(Y)" later in the makefile will evaluate to "1" since that's
what "$(X)" was when "$(Y)" was defined.
;=
VARIABLE ;= expr
override VARIABLE ;= expr
This is the same as "VARIABLE := expr" except that the right hand
side is evaluated only at the time of the first use and then
remembered. This is useful for expensive commands, which always
return the same value, but which you don't want to perform when
building unrelated targets:
VAR1 ;= $(perl expensive calculations)
VAR2 ;= $(shell external command)
Note that old makefiles will usually use ":=" here, to at least do
this only once. But with this operator you can even additionally
not do it, if you currently don't need the value. For values which
are identical in several directories, you can optimize this further
with "global", discussed below.
However this is not intended as a clever way to force order of
evaluation. If a variable defined like this includes the value of
another variable, and that other one has a target specific value,
and the first expansion is for that target, then the target
specific value will stick for all other contexts as well. This is
a bug and will hopefully be fixed in the future.
+=
VARIABLE += expr
override VARIABLE += expr
Appends the string to the previous contents of the variable,
separated by a space. If the variable was previously assigned with
":=", then the right hand side is evaluated before appending.
&=
VARIABLE &= expr
override VARIABLE &= expr
Prepends the string to the previous contents of the variable,
separated by a space. If the variable was previously assigned with
":=", then the right hand side is evaluated before appending.
For example one way of guaranteeing that "CFLAGS", whatever else
the user may put in, always starts with "-Wall" are these two
lines:
CFLAGS = -O2 # Possibly overridden on the command line
override CFLAGS &= -Wall # Unconditionally prepended
In old makefiles you typically had to do something like this, which
had the side effect of forcing the type to ":=" to prevent endless
recursion:
VARIABLE := expr $(VARIABLE)
?=
VARIABLE ?= expr
override VARIABLE ?= expr # Useless, but legal
Sets the value of the variable, but only if the variable is not
specified earlier in the makefile, on the command line, or in the
environment. The above assignment is exactly equivalent to
ifndef VARIABLE
VARIABLE = expr
endif
!=
VARIABLE != shell command
override VARIABLE != shell command
Runs the shell command and sets the variable to contain the
command's standard output. This is exactly equivalent to
VARIABLE := $(shell command)
Multiline variables
The "define" statement is the multiline equivalent of the simple
statements above. The operator after the variable is optional. If
missing, it is equivalent to "define VARIABLE =". The "&=" and "+="
operators are slightly different here, in that they glue this to the
old value with a newline, rather than a space. There must not be
anything except a comment after the statement, i.e. the value starts on
the next line.
define VARIABLE :=
first line of variable's value
second line of variable's value
third line of variable's value
endef
override define VARIABLE
...
enddef
Keywords before "define" can be combinations of either one of "export"
or "global" and "override".
If you need a variable's value to contain newlines, you must use the
"define" statement as shown (or you can assign the value directly in
Perl). ("endef" was chosen for compatibility with GNU make. You may
also use "enddef".) This is primarily useful for "canned command
sequences", e.g., something like this:
define COMPILE_C_PROGRAM
@&echo "Compiling $(input)"
@$(CC) $(CFLAGS) $(CPPFLAGS) $(INCLUDES) -c $(input) -o $(output)
endef
Then you can use this multi-line variable in several rules, like this:
%.o : %.c
$(COMPILE_C_PROGRAM)
$(ARCH)/%.o : $(ARCH)/%.c
$(COMPILE_C_PROGRAM)
Note that you can often achieve the same effect by using a semicolon
instead of a newline, because the shell interprets that as a command
delimeter too. For example,
COMPILE_C_PROGRAM = @echo "Compiling $(input)"; \
$(CC) $(CFLAGS) $(CPPFLAGS) $(INCLUDES) -c $(input) -o $(output)
will have the same effect, except that the semicolon forces Perl to
pass it to the shell, instead of executing the command directly and
more efficiently. You also have to put each builtin on a line of its
own, meaning that you have to switch to the external echo in the
semicolon case.
There is one speciality when expanding within "define", i.e. "define X
:=" or on a variable that was already ":=", "define X &=" and "define X
+=". In this case the "$(shell command ...)" or builtin "$(&command
...)" do not get newlines transformed into spaces.
Exporting variables to subprocesses
export VAR ...
export VAR = value
override export VAR += value
The first form marks the given variables for export to subprocesses,
with whatever value the variable then has. The second form, which
applies only to one variable, additionally assigns a value right away.
All the variants of assignment are allowed.
Sharing variables across makefiles
global VAR ...
global VAR = value
override global VAR &= value
The first form marks the given variables as global to all makefiles.
If any of them already had a value, that value is moved from the
makefile local variable to the global one. However if, at the time
this statement is seen, any other makefiles already had a value for any
of them, then those makefiles will not see the global one.
The second form, which applies only to one variable, additionally
assigns a value right away. All the variants of assignment are
allowed. Note that ":=" will expand right away to the values in the
local makefile. On the contrary "=" variables will expand to the
values at the point of use.
Global variables can be tricky to deal with, because makepp may load
makefiles in any order, as the need arises to build some target for
which no rule or makefiles is loaded. For this reason it is
recommended to have a RootMakeppfile and to explicitly load all others
which modify or use the variable with "load-makefile".
global GLIBLIBS ;= $(shell pkg-config --libs glib-2.0)
Also note that your project may some day be built together with other
projects. For this reason it is recommended to always make the project
name part of any global variable name.
Target-specific assignments
target: VARIABLE = string
target: VARIABLE := string
target: override VARIABLE += string
Sets a target-specific value of the variable. A target-specific value
is in effect only in an action which produces the given target. This
is primarily used for things like this:
CFLAGS := -O2
my_prog: file1.o file2.o special_file.o
special_file.o : CFLAGS := -g
%.o: %.c
$(CC) $(CFLAGS) -c $(input) -o $(output)
What happens here is that all ".c" files will be compiled with
optimization ("-O2") except "special_file.c", which is compiled in
debug mode ("-g"). This is a convenient way to specify different
compilation options for only a few files.
Target-specific variable assignments like this apply only to the
actions of the rule; they are not in effect when evaluating the targets
or the dependencies of a rule. If a rule has more than one target,
target-specific variable assignments are taken only from the first
target. Also note that makepp's target-specific variables are slightly
different from GNU make's in that they only apply to the rule for the
one file mentioned, and not to any of its predecessors.
Wildcard expansion is performed on the target, so you can do something
like this:
test_*.o : CFLAGS += -DTEST
For compatibility with GNU make, "%" may be used in place of "*".
Variable Substitution
Makepp's variable substitution rules are similar to those of other
makes, but somewhat more powerful. As in all makes, "$(CC)" or "${CC}"
both represent the value of the variable CC. If you need a literal
dollar sign, put in a double dollar sign ($$), like this:
target: dep1 dep2 dep3 dep4
&rm -f $(output)
for file in $(inputs); do cat $$file >> $(output); done
Additionally makepp has a "$[VARIABLE]" syntax, which does the same
thing as the other two, but before makepp groks anything else. This
allows using it for complete rules and/or conditionals:
define bracket_rule =
ifdef SOME_VAR
bracket:
&echo this is a rule -o $(output)
endif
enddef
$[bracket_rule]
rc-style substitution
By default, makepp uses rc-style substitution (so called because it was
pioneered by the rc shell). This is best illustrated by an example:
MODULES = a b c d
mylib.a : module_dir/$(MODULES).o $(OTHER_OBJECTS)
$(CXX) $(dependencies) -o $(target)
The prefix "module_dir/" is prepended to each word in MODULES, and the
suffix ".o" is appended to each word.
You can also use rc-style substitution without even putting the list of
words into a variable; the syntax is "$( word1 word2)". Note the space
between the parenthesis and the first word. So the above example could
have been written as:
mylib.a : module_dir/$( a b c d).o $(OTHER_OBJECTS)
$(CXX) $(dependencies) -o $(target)
A variable will give rc-style substitution only when there is more than
one word in it. With one word it is like traditional make. Alas, when
the variable is empty, there is a conflict. Traditional makes simply
expand it to the empty string. But when you think of it as a list,
you'd want "-I$(DIRLIST)" to disapear, not to give a lonely "-I". The
solution is to wrap it into a list that starts with a space: "-I$(
$(DIRLIST))" gives you exactly as many options, as there are words in
the list.
If you put several variables in the same word which expand to arrays of
words, rc-style substitution actually takes the cartesian product, so
you can do something like this if you want:
DIRS = s1 s2
MODULES = a b c
SUFFIXES = .o .c
FILES := $(DIRS)/$(MODULES)$(SUFFIXES)
and FILES will contain the string
s1/a.o s1/a.c s1/b.o s1/b.c s1/c.o s1/c.c s2/a.o s2/a.c s2/b.o s2/b.c s2/c.o s2/c.c
If rc-style substitution gets in the way, or if you need to have
leading or trailing whitespace in your make variables, then you can
turn off rc-style substitution by setting the variable
"makepp_simple_concatenation=1". You can turn it off globally on the
command line or as an environment variable. Or on a per-makefile basis
by setting the variable in your makefile. You should do this near the
top of the makefile, or else you may run into funny situations where
rc-style substitution is used for some evaluations and not others.
(All expressions evaluated before the assignment will use rc-style
substitutions, and all expressions evaluated after will not. Since the
time of evaluation of expressions in makefiles is complicated and not
always obvious from the order of statements in the makefile, it's best
to set "makepp_simple_concatenation" as early as possible.) You can
even set it just for one target:
target: makepp_simple_concatenation = 1
target:
&echo before_first$(LIST)after_last -o $(output)
Because "$[VARIABLE]" is evaluated earlier than "$(VARIABLE)",
combining the two in rc-substitution will not give the result you may
expect:
A = a b
N = 1 2
X := $(A)$[N]
The last line gets read as
X := $(A)1 2
which gives "X" a value of "a1 b1 2".
Substitution References
A substitution reference has the form "$(VAR:A=B)", where A is a
pattern to match and B is a pattern to replace it with. For example:
source_files = a.c b.c c.c d.c
object_files = $(source_files:%.c=%.o)
will set "$(object_files)" to "a.o b.o c.o d.o". The "%" is a special
character matches any arbitrary string. Substitution references are an
abbreviation fot the "patsubst" function.
Whitespace in variables
If you need to control the whitespace in a variable, you must
(currently) disable rc-style substitution (by setting
"makepp_simple_concatenation=1") and then use a syntax like this:
null =
T = -o $(null)
or, with an empty evaluation:
T = -o $()
When you do this, the variable "T" contains "-o" followed by a space.
This kind of a technique to handle whitespace is not recommended. If
you need variables in your makefile to contain spaces, you should think
seriously about what you're doing. If you need to handle spaces, it is
usually much better to put Perl code into your makefile to take care of
it (using the "perl_begin" or "sub" statements), or to handle it in
shell statements in the actions of rules.
These cases typically come up when people attempt to use the same rules
for different architectures which do not use typical Unix command
syntax. E.g., sometimes one sees things like this in makefiles:
ifeq ($(ARCH),weirdarch)
O := /OUTPUT=
else
null :=
O := -o $(null)
endif
%.o : %.c
$(COMPILER) $(input) $(O)$(output)
You can do this with makepp if you really want to, but you will
probably find that your makefiles are substantially more readable if
you have less complicated variable substitution, e.g.,
ifeq ($(ARCH),weirdarch)
%.o : %.c
$(WEIRD_COMPILER) $(input) /OUTPUT=$(output)
else
%.o : %.c
$(CC) -c $(input) -o $(output)
endif
Whitespace is never allowed in variable names, only in their values.
This is different from some make implementations.
Automatic Variables
Automatic variables are variables that assume different values
depending on which rule they are evaluated in. Makepp supports most of
the automatic variables that other versions of make use. In addition,
it has less cryptic, longer names for most of them that you can use
instead. (For legacy makefiles that happen to redefine these names,
the definition in the makefile overrides the default meaning. For
example, if you say "target = abc" in your makefile, then "$(target)"
will always expand to "abc", and will no longer be equivalent to $@.)
The following is a complete list of all the automatic variables that
makepp supports:
output
target
$@ The target of the current rule. Actually, since makepp supports
multiple targets for any rule, this is the first target. For
example, in the following rule
y.tab.c y.tab.h : parser.y
$(YACC) -o $(output) $(YFLAGS) $(input)
"$(output)" will contain the value y.tab.c. Since these magic
variables are in fact functions, you can also pass an index as
argument. This counts from 1 or backwards from -1. So "$(output
2)" or "$(output -1)" will contain the value y.tab.h.
While all three forms of this variable have the same value, there
is a difference in interpretation for multitarget rules. If you
use the old-style cryptic name $@, makepp will interpret that as an
old-style rule set, rather than a modern rule that produces all
those targets in one go:
a b: # really: one rule each for a and b
touch $@
c d: # error: mpp complains that this didn't build d
touch $(output)
outputs
targets
All targets of the current rule. Same as "$(target)" unless there
is more than one target. In the above example, "$(outputs)" will
be y.tab.c y.tab.h. You can pass an index list, so "$(outputs 2
1)" will be y.tab.h y.tab.c.
dependency
input
$< The first explicit dependency of the rule. For example, in this
rule
%.o : %.c
$(CC) $(CFLAGS) -c $(input) -o $(output)
"$(input)" will be the name of the .c file, regardless of what .h
files makepp discovers. If you specify more than one dependency,
you can get them by passing an index: "$(input $(INDEX))" is the
INDEXth dependency.
dependencies
inputs
$^ All the explicit dependencies of the target, not including .h files
discovered by makepp_scanning for includes.
For example, in the rule
myprog.o : *.o
$(CC) $(CFLAGS) $(inputs) -o $(output)
"$(inputs)" will be all the .o files in the directory. You can
pick only the ones you want by passing an index list. If you
explicitly specify different kinds of files, you can pick them as
in "$(inputs 2 3 4)" (but with a wildcard this is not too
promising).
sorted_dependencies
sorted_inputs
$+ All the dependencies of the target, in sorted order, with
duplicates removed. Equivalent to "$(sort $(inputs))".
changed_dependencies
changed_inputs
$? The dependencies of the target that have changed. This includes
only explicit dependencies (i.e., ones you list in the makefile),
not implicitly discovered dependencies from scanning (such as .h
files).
This is commonly used in commands like this:
libmine.a : $(MODULES) : build_check ignore_action
$(AR) ru $@ $?
i.e., ar is told to replace only those modules that have changed.
(Note the "ignore_action" build check rule. If you don't specify
this, makepp will force the action to be executed whenever it
changes. If no dependencies have changed, the action string will
be "ar ru libmine.a" which is probably different from what it was
last time you ran it, so without "ignore_action" makepp will
execute it. In this case, it's harmless, but with other commands,
it could be a problem. See makepp_build_check for details on
"ignore_action".)
Building archives like this is not a good idea because it will make
your builds less reliable. The problem with this is that if you
build the archive, then remove one of the modules from the list of
MODULES, the modules will still be in the archive and makepp
stem
$* The stem in a pattern rule (i.e., whatever the '%' matched).
Alternatively, if this is not a pattern rule, returns the file name
without the extension (i.e., it's equivalent to
"$(basename $(input))".
This is mostly for backward compatibility. For example, in old
versions of make the only way to tell it how to compile any .c file
into the corresponding .o file was like this:
.c.o:
$(CC) $(CFLAGS) -c $*.c -o $*.o
This is a lousy way to write the rule. It's much clearer to use
GNU-make style pattern rules, like this:
%.o : %.c
$(CC) $(CFLAGS) -c $(input) -o $(output)
foreach
The current filename from the "foreach" clause. "foreach" clauses
are rarely used, but they are the most general-purpose kind of
pattern rule that makepp supports. For example,
#
# Build .c files with some sort of a special preprocessor:
#
%.c : %.k
$(preprocessor) $(input) > $(output)
#
# Compile .c files into .o files:
#
%.o : %.c
$(CC) $(CFLAGS) -c $(input) -o $(output)
#
# Special alternate compilation flags for .c files which are derived
# from .k files:
#
$(foreach:%.k=%.o) : $(foreach:%.k=%.c) : foreach *.k
$(CC) $(SPECIAL_K_FLAGS) -c $(input) -o $(output)
See the documentation on the foreach clause in rules for more
details and examples.
$/ This is essentially a constant, either "/", or on native Windows
"\". You need it, if you want to start a program portably, e.g.
one you built in the current directory:
myoutput:
.$/myprog >$(output)
For filenames passed as arguments it is not so necessary as Windows
can handle Unix syntax there.
Predefined Variables
Makepp predefines a few variables, which you can override:
AR Default: "ar".
ARFLAGS
Default: "rv".
AS Default: "as".
CC Default: The first found among "gcc", "egcc", "pgcc", "c89" or
"cc", or on Windows additionally "cl" or "bcc32".
CFLAGS
Default: If "$(CC)" is a Gnu compiler "-g -Wall", if it is one of
the two Windows compilers nothing, else "-g".
CURDIR
The directory in which the current Makefile resides.
CXX Default: The first found among "g++", "c++", "pg++", "cxx", "C""C"
or "aCC", or on Windows additionally "cl" or "bcc32".
CXXFLAGS
Default: If "$(CXX)" is a Gnu compiler "-g -Wall", if it is one of
the two Windows compilers nothing, else "-g".
F77 Default: The first found among "f77", "g77" or "fort77".
FC Default: "$(F77)".
LD Default: "ld".
LEX Default: The first found among "lex" or "flex".
LIBTOOL
Default: "libtool".
MAKE
This variable has two different values, depnding on the presence or
not of "--traditional-recursive-make". Makepp recognizes when this
variable is used and turns off some features, even before the
recursion actually takes place. This can be undesirable while you
are gradually eliminating it, so first convert the calls to a
makepp specific "$((MAKE))", which will not turn off features.
MAKECMDGOALS
This variable is set but not used by makepp. You can query it to
do something only if a certain target was requested.
Default: Whatever explicit targets the user (or a recursive
invocation) provided. Empty when implicitly building default
target.
ifneq $(filter special-target, $(MAKECMDGOALS))
# special-target is one of the current explicit targets
else ifeq $(MAKECMDGOALS)
# no explicit targets
endif
MAKEFLAGS (exported)
The standard options with which makepp was called. Those that have
a single letter form are combined at the beginning without a
leading "-" (heaven knows why gmake chose to drop the "-").
MAKEINFO
Default: "makeinfo".
MAKEPPFLAGS (exported)
This is set to the same value as MAKEFLAGS, but only if this
variable is present in makepp's environment.
_MAKEPPFLAGS (exported)
The makepp specific options needed for POSIX/gmake compatibility,
with which makepp was called. These are in a separate variable so
a legacy makefile can't break compatibility by unsetting MAKEFLAGS.
This is only set with "--traditional-recursive-make".
MAKEPP_LN_CP
See the note under &ln.
makepp_percent_subdirs
Set this to some true value (like 1) to have "%" in targets or
dependencies match across more than one directory.
Default: undefined
makepp_require_phony
Set this to some true value (like 1) to prevent implicit phonyness
(i.e. if a rule succeeds without producing its target). This
variable should be true by default, to prevent broken dependency
chains, but that would break backward compatibility with sloppy
makefiles.
Default: undefined
makepp_simple_concatenation
Set this to some true value (like 1) to prevent "rc-style
substitution".
Default: undefined
MAKEPP_VERSION
The version of makepp you are running with. If it is a beta
version, it will have a hyphen followed by YYMMDD plus some more
internal data. You can use this for "ifdef" to hide makepp
specific constructs from other makes.
Default: The same value displayed by "makepp --version"
PWD An alias for "CURDIR".
RM Default: "rm -f". This is meant for legacy Makefiles. For new
ones preferably use the builtin &rm command directly. If you want
to write a phony clean rule, look at the "makeppclean -r" command
instead.
ROOT
The relative path to the root of your build system, i.e. the
directory further up in which you have a "RootMakeppfile(.mk)". If
you don't have one, this variable is empty.
SHELL
This variable is only respected if you "export" it. In that case
it is the Shell which is used to execute not-builtin actions with
some special character in it (plain ones being exec`ed directly).
On Windows Strawberry or ActiveState Perl, if you have a Unix-like
Shell, you must instead set your SHELL variable to a value ending
in "sh" or "sh.exe" before calling makepp.
Default: The first found among "/usr/xpg4/bin/sh" (e.g. Solaris) or
"/sbin/xpg4/sh" (e.g. Reliant Unix) or "/bin/sh".
YACC
Default: The first found among "bison -y" or "yacc".
VPATH
Setting this variable to some value implicitly calls "vpath %
value".
Default: undefined
Variables and Perl
Variable values are stored as ordinary Perl scalars, so you can access
them directly from Perl code if you need to do any complicated
manipulations with them; see makepp_extending for details.
Accessing global variables from Perl is achieved by prefixing them with
the "Mpp::global" package. In fact any variable, not yet present in
the current makefile, and which you assign to in this package will from
then on be global, as though you had just issued the "global" statement
for it.
This direct access is however error-prone! The user may have
overridden these variables on the command line or through the
environment. Some other makefile loaded before this one may have made
the variable global or target specific. In these cases you would not
find the value of the variable, or when assigning it, might take away
its property (equivalent to an "override" modifier, except for target
specifics.)
With direct access you also bypass the expansion of these variables, if
they are of type "=" or ";=". Special variables like "$(CC)" start out
as functions, until they are assigned to. So in many cases you won't
see their value.
For these reasons it is better to let makepp determine the correct
value. You can use the "makeperl" variant, in which the variable has
been evaluated before the Perl code gets interpreted:
makeperl { $$current_value = '$(MAKEFILE_VAR)' }
If you need a variable in makefile perl blocks this is achieved via the
Perl variable $makefile as follows:
perl { $current_value = $makefile->expand_variable( 'MAKE_VAR' ) }
Functions always get the makefile object passed in as the second
argument $_[1]:
sub f_f { $current_value = $_[1]->expand_variable( 'MAKE_VAR' ) }
Commands are supposed to be called within a rule action, where the
makefile object is accessible via "$Mpp::Subs::rule->{MAKEFILE}":
sub c_cmd { $current_value = $Mpp::Subs::rule->{MAKEFILE}->expand_variable( 'MAKE_VAR' ) }
AUTHOR
Gary Holt (holt-makepp@gholt.net)
POD ERRORS
Hey! The above document had some coding errors, which are explained
below:
Around line 11:
alternative text '$/' contains non-escaped | or /
perl v5.20.3 2012-02-28 MAKEPP_VARIABLES(1)
