xenial (1) makepp_variables.1.gz

Provided by: makepp_2.0.98.5-1_all bug

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,
         MAKEPP_DEBUG,
         MAKEPPFLAGS,
         _MAKEPPFLAGS,
         MAKEPP_LN_CP,
         "makepp_percent_subdirs",
         "makepp_require_phony",
         makepp_signature_C_flat,
         "makepp_simple_concatenation",
         MAKEPP_VERSION,  O: "output",
         "outputs",  P: PERL,
         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

       Besides white space, rc-style substitution stops at any quote, any round, curly or square parentheses,
       and any of ", : ; = # @".  Note that this may be surprising, and again need an explicit list.  Say you
       want to look for headers by wildcard in all directories starting with an upper-case letter:

           BAD := [A-Z]*/**/*.$( hpp h)        # [A-Z]*/**/*.hpp */**/*.h
           GOOD := $( [A-Z]*/**/*.)$( hpp h)   # [A-Z]*/**/*.hpp [A-Z]*/**/*.h

       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, unless you wrap it in an explicit list:

           A = a b
           N = 1 2
           BAD := $(A)$[N]
           GOOD := $(A)$( $[N])

       The last lines get read as

           BAD := $(A)1 2      # a1 b1 2
           GOOD := $(A)$( 1 2) # a1 a2 b1 b2

       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.  Substitution references are an abbreviation for the "patsubst" function.  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.  If both A and B start with "%", a common case when replacing suffixes, they can be omitted:

           object_files = $(source_files:.c=.o)
           object_files = $(source_files:c=o) # same, because . is not special

       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.

   Option Variables
       You can set these in all the ways explained above (except if stated otherwise) to modify the bahaviour of
       makepp.  By default they are all undefined.

       MAKEPP_DEBUG
           If you export this with a true value before calling makepp, you get more debugging info.  This is the
           "RULE_SOURCE" of files built while this is in effect under makeppinfo, mppi and details about
           variable expansion and rule matching under makepplog, mppl.  This will also show you if makepp runs
           out of memory or hangs, because it is endlessly expanding the same variables:

               A = $A                      # deferred evaluation, need :=
               B = $C
               C = $B

       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.

       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.

       makepp_signature_C_flat
           This is an option to signature C.  Set this to some true value (like 1) to treat your sources as
           flattened, i.e. all newlines (except around preprocessor statements) are treated like whitespace and
           "#line" directives are ignored.

       makepp_simple_concatenation
           Set this to some true value (like 1) to prevent "rc-style substitution".

       PERL
           You can set this to the exact perl you are using to run the scripts in the makepp suite, and export
           it.  This can help to run sub-scripts with the same perl.  This is mostly useful for the test suite,
           the installation and for recursive builds.

       VPATH
           Setting this variable to some value implicitly calls "vpath % value".

   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, depending 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.  You should not set it because that breaks our smart recursion work around.

       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_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".

   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)