Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
MAKEPP_VARIABLES(1)		    Makepp		   MAKEPP_VARIABLES(1)

NAME
       makepp_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.36.3			  2012-02-28		   MAKEPP_VARIABLES(1)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=makepp_variables&sektion=1&manpath=FreeBSD+Ports+14.3.quarterly>

home | help