=head1 NAME
makepp_command -- Command line syntax for makepp
=for vc $Id: makepp_command.pod,v 1.39 2008/06/01 22:01:16 pfeiffer Exp $
=head1 DESCRIPTION
makepp [-options] [VAR=value] [target1 target2 ...]
mpp [-options] [VAR=value] [target1 target2 ...]
L<--B<A>|/_2dI_3dfilename>,
L<--assume-new|/_2DW_filename>,
L<--argsfile|/_2d_2dargsfile_3dfilename>,
L<--assume-old|/_2Do_filename>,E<nbsp>
L<-B<b>|/_2d_2dbuild_2dcache>,
L<--build-cache|/_2d_2dbuild_2dcache>,
L<--build-check|/_2d_2dbuild_2dcheck_3dmethod>,E<nbsp>
L<-B<c>|/_2dc>,
L<-C|/_2dc_dirname>,E<nbsp>
L<--B<d>irectory|/_2dc_dirname>,
L<--do-build|/_2D_2Ddo_2Dbuild_3Dfilename>,
L<--do-read|/_2D_2Ddo_2Dread_3Dfilename>,
L<--dont-build|/_2D_2Ddont_2Dbuild_3Dfilename>,
L<--dont-read|/_2D_2Ddo_2Dread_3Dfilename>,
L<--dry-run|/_2Dn>,
L<--dump_makefile|/_2D_2Ddump_2Dmakefile_3Dfilename>,E<nbsp>
L<-B<e>|/_2De>,
L<--env-overides|/_2De>,
L<--environment-overides|/_2De>,E<nbsp>
L<-B<f>|/_2df_makefile>,
L<-F|/_2df_makeppfile>,
L<--file|/_2Df_makefile>,
--final-rules-only,
L<--force-copy-from-bc|/_2d_2dforce_2dcopy_2dfrom_2dbc>,
--force-rebuild,
--force-rescan,E<nbsp>
--B<g>ullible,E<nbsp>
L<-B<I>|/_2di_dir>,
--implicit-load-makeppfile-only,
L<--include|/_2di_dir>,
L<--include-dir|/_2di_dir>,
--in-sand-box,
--inside-sand-box,E<nbsp>
L<-B<j>|/_2Dj_n>,
L<--jobs|/_2Dj_n>,
L<--just-print|/_2Dn>,E<nbsp>
L<-B<k>|/_2Dk>,
L<--keep-going|/_2Dk>,E<nbsp>
L<--B<l>og-file|/_2D_2Dlog_2Dfile_3Dlogfilename>,
L<--load-makefile|/_2d_2dload_2dmakefile_makefile>,E<nbsp>
L<-B<m>|/_2Dm_method>,
L<--makefile|/_2df_makefile>,
L<--makeppfile|/_2df_makeppfile>,E<nbsp>
L<--md5-check-bc|/_2d_2dmd5_2dcheck_2dbc>,
L<-B<n>|/_2Dn>,
L<--no-builtin-rules|/_2D_2Dno_2Dbuiltin_2Drules>,
L<--no-implicit-load|/_2D_2Dno_2Dimplicit_2Dload>,
L<--no-log|/_2D_2Dno_2Dlog>,
L<--no-log-scan|/_2D_2Dno_2Dlog_2Dscan>,
L<--no-path-executable-dependencies|/_2d_2dno_2dpath_2dexecutable_2ddependencies>,
L<--no-populate-bc|/_2d_2dno_2dpopulate_2dbc>,
L<--no-remake-makefiles|/_2D_2Dno_2Dremake_2Dmakefiles>,
L<--no-warn|/_2D_2Dno_2Dwarn>,E<nbsp>
L<-B<o>|/_2Do_filename>,
L<--old-file|/_2Do_filename>,
L<--out-of-sandbox|/_2D_2Dsandbox_3Dfilename>,E<nbsp>
L<--B<p>ercent-subdirs|/_2D_2Dpercent_2Dsubdirs>,
L<--populate-bc-only|/_2d_2dpopulate_2dbc_2donly>
--profile,E<nbsp>
L<-B<q>|/_2Dq>,
L<--quiet|/_2Dq>,E<nbsp>
L<-B<r>|/_2Dr>,
L<-R|/_2DR_dir>,
L<--repository|/_2DR_dir>,
L<--rm-stale|/_2D_2Drm_2Dstale>,
L<--remove-stale|/_2D_2Drm_2Dstale>,
L<--root-directory|/_2dc>,E<nbsp>
L<-B<s>|/_2Ds>,
L<--sandbox|/_2D_2Dsandbox_3Dfilename>,
--sand-box-warning,
L<--signature-method|/__2Dm_method>,
L<--silent|/_2Ds>,
L<--stop|/_2D_2Dstop>,
L<--stop-after-loading|/_2D_2Dstop>,E<nbsp>
--stop-on-race
L<--symlink-in-repository-as-file|/_2D_2Dsymlink_2Din_2Drepository_2Das_2Dfile>,
L<--B<t>raditional-recursive-make|/_2D_2Dtraditional_2Drecursive_2Dmake>,E<nbsp>
L<-B<v>|/_2Dv>,
L<--verbose|/_2Dv>,
L<--version|/_2D_2Dversion>,E<nbsp>
L<--virtual-sandbox|/_2D_2Dvirtual_2Dsandbox>,E<nbsp>
L<-B<W>|/_2DW_filename>,
L<--what-if|/_2DW_filename>
Makepp supports most of the command line options and syntax that other makes
support. The hyphens between the words are always optional, and can also be
replaced by an underscore. You specify a list of targets to build on the
command line. If you do not specify any targets, the first explicit target in
the makefile is built.
You can assign variables on the command line which will override any
assignment or environment variable in every Makefile loaded, e.g.,
makepp CFLAGS=-O2
Options include most of the standard make options, plus a few new ones.
=over 4
=item -A filename
=item --args-file=filename
=item --arguments-file=filename
Read the file and parse it as possibly quoted options on one or several lines.
=item -W filename X<-W> X<--assume-new>
=item --assume-new=filename
=item --what-if=filename
Pretends the specified file has changed, so that any targets that depend
on that file will be rebuilt. The file itself is not necessarily
changed (it might or might not be rebuilt, depending on whether it is up
to date with respect to its dependencies), but everything that depends
on it thinks that it has changed. This can be useful for debugging a
makefile.
=item -o filename X<-o> X<--assume-old>
=item --assume-old=filename
Pretends that the specified file has not changed, even if it has. Any
targets that depend on this file will not be rebuilt because of this
file, though they might be rebuilt if some other dependency has also
changed. The file itself might or might not be rebuilt, depending on
whether it is out of date with respect to its dependencies. (To prevent
that, use C<--dont-build>.)=item -b
=item --build-cache
Specifies the path to a build cache. See L<makepp_build_cache> for details.
The build cache must already exist; see
L<makepp_build_cache/makepp_build_cache_control> for how to make it in the
first place. Build caches defined on the command line may be overridden by a
C<build_cache> statement in a makefile (see L<makepp_statements/build_cache>)
or a C<:build_cache> modifier to a rule (see L<makepp_rules/build_cache>). If
you work with several different builds, it may be useful to set the
environment variable C<MAKEPPFLAGS> to contain
C<--build-cache=/path/to/build/cache> so that all of your builds will take
advantage of the build cache by default.
=item --build-check=method
=item --build-check-method=method
The name of a build check method to use to decide whether files need tobe rebuilt. See L<makepp_build_check> for information on build check
methods.
=item -e
=item --env-overides
=item --environment-overides
Causes variables from the environment to override definitions in the
makefile. By default, assignments within the makefile override variable
values which are imported from the environment.
=item -c
=item --root-directory
Cd up to the directory containing a RootMakeppfile.
=item -C dirname X<-C> X<--directory>
=item --directory=dirname
Cd to the given directory before loading the makefile and trying to build the
targets. This is more or less equivalent to specifying a directory with
C<-F>, except that subsequent C<-C>, C<-f>, C<-F>, C<-I> and C<-R> options are
interpreted relative to the new directory, rather than the old one.
=item --dont-build=filename X<--dont-build>
Do not build the specified file, even if it is listed in a dependency
list. This is useful if you built a specific file by hand using some
extra debugging compilation options. Without this option, if you
compile a module by hand and then run makepp to compile the rest of the
program, makepp will recompile the module you compiled by hand because
it recognizes that the file has changed since it was last built. This
is because makepp cannot guarantee that the build is correct if any of
the files were not built under its control. With this option, you tell
makepp that you really know what you are doing in the case of this
particular file and you promise that it's ok not to rebuild it.
For example,
% cc -g -DSPECIAL_DEBUG -c x.c -o x.o
% makepp
cc -g -O2 -c x.c -o x.o
cc x.o y.o -o my_program
% cc -g -DSPECIAL_DEBUG -c x.c -o x.o
% makepp --dont-build x.o
cc x.o y.o -o my_program
If you want special compilation options for just one module, it's often
easier to edit the makefile than to compile by hand as in this example;
see L<makepp_variables/Target-specific assignments> for an easy way of
doing this.
If the specified file is a directory that already exists, then files below the
directory inherit the dont-build property. And C<--dont-build> can override a
C<--do-build> inherited from a directory higher up.
If you put a F<RootMakeppfile(.mk)> at the root of your build system, that
directory and everything under it defaults to C<--do-build>, while the overall
root of your file system defaults to C<--dont-build>. That way, everything
inside your build system is built (if necessary) but nothing outside is
attempted. If, in this scenario, you want external parts to always be built
as needed, you must exlicitly pick them up with C<load_makefile> statements in
one of the makefiles within your tree.
You may have one F<RootMakeppfile(.mk)> each, in separate build trees, and
they will be loaded if one tree has dependencies in another one. But you are
not allowed to have F<RootMakeppfile(.mk)> in nested directories, avoiding
funny effects that tend to arise when you accidentally call C<makepp
--repository> again in a subdirectory. These effects include duplicate rules
through duplicate sources, or eternal buld cache reimports because cached
files have the right signatures but the wrong relative pathes.
=item --do-build=filename X<--do-build>
Override C<--dont-build> for the specified file or directory. If you have a
F<RootMakeppfile(.mk)> at the root of your build system, but you want makepp
to build something outside of your build system just this once, you must
explicitly mark it as C<--do-build>. If you specify C<--do-build> for a file
or directory under a F<RootMakeppfile(.mk)>, without C<--dont-build> for a higher
directory, then the root (and all else under it) of your build system defaults
to C<--dont-build>.
To resolve conflicts between C<--dont-build> and C<--do-build>, the one
with the most specific path takes precendece regardless of order.
If the same path is specified with both C<--dont-build> and C<--do-build>,
then the rightmost one wins.
The options C<--dont-build> and C<--do-build> can be dangerous if you give the
wrong hints to makepp, since you are asking makepp not to do checks it needs,
to guarantee a correct build. But since they allow greatly reducing the
number of checks, they can speed up your builds dramatically, as explained in
L<potentially unsafe speedup methods|makepp_speedup/Potentially Unsafe Methods>.
=item --sandbox=filename X<--sandbox>
=item --out-of-sandbox=filename X<--out-of-sandbox>
Generate an error rather than write files outside the "sandbox". Like
--dont-build, more specific paths override less specific paths. The
filesystem root defaults to out-of-sandbox if there are any C<--sandbox>
options.
The purpose of the sandbox is to enable multiple concurrent makepp processes
to safely operate on disjoint parts of the filesystem. In order for this
to work reliably, concurrent sandboxes must not overlap, and each process
must mark the sandbox of every other concurrent makepp process for
L<--dont-read|/_2D_2Ddont_2Dread_3Dfilename>.
=item --do-read=filename X<--do-read> X<--dont-read>
=item --dont-read=filename
Generate an error rather than read files marked for C<--dont-read>.
See L<--sandbox|/_2D_2Dsandbox_3Dfilename>. The filesystem root always
defaults to readable.
=item --dump-makefile=filename X<--dump-makefile>
Dump the raw contents of the makefileZ<>(s) for the current directory
(as determined by the position of this option relative to any C<-C> options)
to C<filename>.
Include files are interpolated, comments are stripped out and C<ifdef>'s
are resolved.
C<
The final value of any non-reference scalars in the makefile's package areprinted following the makefile.
This is useful for debugging, but (currently) you won't necessarily be able
use the dump file as an equivalent makefile, for example because it containsboth the include statement and the interpolated file.
=item -f Makefile X<-f>
=item --file=Makefile
=item --makefile=Makefile
Uses the specified makefile. If you do not specify the C<-f> option or the
C<-F> option, makepp looks first for a file in the current directory (or the
directory specified by the rightmost C<-C> option, if any) called
C<RootMakeppfile>, then C<RootMakeppfile.mk>, C<Makeppfile>, then
C<Makeppfile.mk>, then C<makefile>, then C<Makefile>.
The first two are special (whether given explicitly or found implicitly).
There should be only one of those two in any given build tree on which makepp
is to operate. But there may be several if you build several disjoint trees
in one go. Those two are looked for not only in the aforementioned directory,
but also upwards from there. If one is found, it is loaded before any other.
=item -F Makeppfile X<-F>
=item --makeppfile=Makeppfile
Loads the specified makefile in lieu of the makefile in the current directory,
and any target specified to the right of this option is interpreted relative
to the directory containing the Makefile. If you specify a directory instead
of a Makefile, searches for C<RootMakeppfile>, C<RootMakeppfile.mk>,
C<Makeppfile>, C<Makeppfile.mk>, C<makefile>, and C<Makefile>. (See the
explanation at the previous option.) Multiple C<-F> options may be specified.
This option can be useful if you execute makepp from unpredictable
directories. For example, if you compile from within emacs and you have
sources scattered all over your directory tree, the current working directory
for the compilation command will be the directory the last source file you
edited was in, which may or may not be the top level directory for your
compilation. However, you can specify your compilation command as
makepp -F /your/source/dir/top
and this will work no matter what your current directory is.
Because this option doesn't affect the directory relative to which subsequent
C<-C>, C<-f>, C<-F>, C<-I> and C<-R> options are specified, you can make
targets relative to the current directory like this:
makepp -F /foo/bar -C . mytarget
=item --load-makefile=Makefile X<--load-makefile>
=item --load-makeppfile=Makefile
Loads the specified makefile I<before> any other makefiles, but do not
consider this option for the purposes of determining the default target. If
no other makefile is specified, then one is sought using the usual rules. If
the specified makefile is the same makefile that is found using the usual
rules, then this option has no effect.
=item --force-copy-from-bc
When using build caches, always copy files in and out of the cache, even if
the source and target are on the same filesystem. This is mainly useful for
testing (emulating) the case in which they are not.
=item -h
=item --help
Print out a brief summary of the options.
=item -j n X<-j>
=item --jobs=n
Interprets the next word as the number of shell commands that can be
executed in parallel. By default, C<makepp> does not execute commands
in parallel.
Unlike some other versions of make, when jobs are executed in parallel,
makepp directs their output to a file and only displays the output when
the commands have finished. This prevents output from several different
commands from being mixed together on the display, but it does mean that
you might have to wait a little longer to see the output.
=item -k
=item --keep-going
Build as many files as possible, even if some of them have errors. By
default, makepp stops when it encounters the first error, even if there
are other files that need to be built that don't depend on the erroneous
file.
=item --log-file=logfilename
Changes the name of the log file to the indicated name. By default, the
log file is called C<.makepp_log>.
=item --no-implicit-load
Don't automatically load makefiles from directories referenced (see
L<makepp_build_algorithm/Implicit loading>). By default, makepp automatically
loads a makefile from any directory that contains a dependency of some target
it needs to build, and from any directory that is scanned by a wildcard.
Sometimes, however, this causes a problem, since makefiles need to be loaded
with different command line varaibles or options, and if they are implicitly
loaded before they are explicitly loaded by a recursive make invocation or the
C<load_makefile> statement, makepp aborts with an error. You can also turn
off makefile loading on a directory-by-directory basis by using the
C<no_implicit_load> statement in one of your makefiles.
=item --implicit-load-makeppfile-only
If implicit loading of makefiles is enabled, then automatically load only a
file called C<RootMakeppfile>, C<RootMakeppfile.mk>, C<Makeppfile>, or
C<Makeppfile.mk>, and I<not> C<makefile> or C<Makefile>. This is useful if
makepp has dependencies that are generated by some other flavor of make, and
makepp can't read that flavor's makefiles in general. (You want to avoid this
situation if possible, but it tends to arise while you're in the process of
porting a legacy build system to makepp.) This has no effect if implicit
loading is disabled.
=item -I dir
=item --include=dir
=item --include-dir=dir
Search I<dir> for included makefiles.
=item --rm-stale X<--rm-stale>
=item --remove-stale
Ignore stale files rather then treating them as new source files, removing
them if necessary in order to prevent them from being read by a build command.
This is not the default because it deletes things, but it is often required
in order for incremental building to work properly.
For example, assume that there is an F<x.c> file that looks like this:
int main() { return X; }
Consider this makefile:
$(phony default): x
x.h:
&echo "#define X 1" -o $@
At some point, you change the makefile to look like this:
CFLAGS := -Idir
$(phony default): x
dir/x.h:
&mkdir -p $(dir $@)
&echo "#define X 2" -o $@
Now if you build from clean, F<x> exits with status 2, but if you build
while the old F<./x.h> file still exists and you don't specify C<--rm-stale>,
then F<x> exits with status 1, because the include directive picks up the
stale generated header file.
If you build with C<--rm-stale>, then F<./x.h> is removed, and the result
is the same as that of a clean build, which is almost always a good thing.
=item -m method X<-m>
=item --signature-method=method X<--signature-method>
Specifies the default signature method to use for rules which do not
have the C<:signature> modifier in makefiles which do not have a
C<signature> statement. Possible values are C<target_newer>,
C<exact_match>, C<md5>, and C<c_compilation_md5>. This option has no
effect on the signature method for C/C++ compilation; you must use theC<signature> statement or the C<:signature> rule modifier to affect
that. For more details, see L<makepp_signatures>.
=item -n
=item --just-print
=item --dry-run
Print out commands without actually executing them. This allows you to
see what makepp will do, without actually changing any files.
More precisely, makepp executes all recursive make commands as normal
(but hopefully you're not using recursive make anywhere!). Other
commands are simply printed without being executed. Even commands which
are prefixed with C<@> or C<noecho> are printed after the C<@> or
C<noecho> is stripped off.
B<Warning:> The commands that makepp executes with C<-n> are not
necessarily the same thing it will do without C<-n>. File signatures do
not change at all with C<-n>, which means that makepp cannot perform
exactly the same build tests that it does when the signatures are
changing. This will occasionally make a difference if you are using MD5
signatures (which is the default for compilation commands) or if you
have shell commands that might or might not change the date.
For example, suppose that you generate a F<.h> file via some sort of
preprocessor. This can happen in a lot of different ways. For
concreteness, suppose you automatically generate a list of prototypes
for functions defined in each C module (see
prototypes.h : *.c
cproto $(CPPFLAGS) $(inputs) > $(output)
Then each F<.c> file will include F<prototypes.h>. The purpose of this
is to maintain the forward declarations for all functions automatically,
so if you change a function's signature or add a new function, you don't
ever have to put in forward or extern declarations anywhere.
Now suppose you change just one F<.c> file. What happens when you run
makepp with C<-n> in this case is that it realizes that F<prototypes.h>
needs to be remade. In all probability, remaking F<prototypes.h> won't
won't affect its signature--the file contents will probably be identical
because no function arguments have been changed--so most of the time,
nothing that depends on F<prototypes.h> actually has to be recompiled.
But makepp doesn't know that unless it's actually allowed to execute the
commands. So it assumes that anything that depends on F<prototypes.h>
will also have to be recompiled. Thus in this example, changing one
F<.c> file will cause S<C<makepp -n>> to think that every single F<.c>
file needs to be recompiled, even though most likely the regular
C<makepp> command will actually not run all those commands.
This situation isn't all that common, and can only occur if (a) you use
a signature method that depends on file contents rather than date, as
the default compilation signature method does, or (b) if you have shell
commands that don't always change the date. E.g., with a traditional
implementation of make that only looks at dates instead of file
signatures, sometimes people will write commands like this:
prototypes.h : $(wildcard *.c)
cproto $(CPPFLAGS) $(inputs) > junk.h
if cmp -s junk.h prototypes.h; then \
rm junk.h; \
else \
mv junk.h prototypes.h; \
fi
Thus if rerunning cproto on all the files produces exactly the same file
contents, the file date is not updated. This will have exactly the same
problem as the above example with S<C<makepp -n>>: it is not known
whether the date on F<prototypes.h> changes unless the command is
actually run, so S<C<makepp -n>> cannot possibly be 100% accurate.
(Note that using the traditional S<C<make -n>> will also have exactly
the same problem on this example.)
S<C<makepp -n>> should always print out more commands than a regular
invocation of C<makepp>, not fewer. If it prints out fewer commands, it
means that makepp does not know about some dependency; some file is
changing that it is not expecting to change on the basis of what it
knows about what files each rule affects. This means that your makefile
has a bug.
=item --md5-check-bc
When importing from a build cache, reject cached targets unless the MD5_SUM
is present and matches the imported target.
When populating a build cache, calculate and store the MD5_SUM in the build
info if it isn't there already.
This is slower and leads to more rebuilds, but it guarantees that imported
targets and build info files correspond exactly.
=item --no-log
Don't bother writing a detailed description of what was done to the log
file. By default, makepp writes out an explanation of every file that
it tried to build, and why it built it or did not build it, to a file
called C<.makepp_log>. This can be extremely valuable for debugging a
makefile--makepp tells you what it thought all of the dependencies were,
and which one(s) it thought changed. However, it does take some extra
CPU time, and you might not want to bother.
=item --no-log-scan
Don't bother putting messages about scanning into the log file. This
can help cut down on the irrelevant messages in the log file.
=item --no-path-executable-dependencies
Do not add implicit dependencies on executables picked up from the command
search path.
This is useful for programs such as grep and diff, which always do basically
the same thing even if their implementation changes.
If this option is specified, then makepp assumes that any executable whose
behavior might change will be specified with a name containing a slash.
=item --no-populate-bc
Don't populate the build cache, but still import from it when possible.
This is useful when the environment might cause targets to be generated
differently, but makepp doesn't know about such dependencies.
It's also useful to avoid thrashing the build cache with a huge number
of concurrent writers that might interfere with one another.
=item --no-remake-makefiles X<--noremake-makefiles>
Ordinarily, makepp loads each makefile in, then looks to see whether
there is a rule that specifies how to update the makefile. If there is,
and the makefile needs to be rebuilt, the command is executed, and the
makefile is reread. This often causes problems with makefiles produced
for the standard unix make utility, because (in my experience) often the
make rules for updating makefiles are inaccurate--they frequently omit
targets which are modified. This can cause makepp to remake a lot of
files unnecessarily. You can often solve this problem by simply
preventing makepp from updating the makefile automatically (but you have
to remember to update it by hand).
=item --no-warn
Don't print any warning messages. Most warning messages are about
constructs that you might see in legacy makefiles that makepp considers
dangerous, but a few of them concern possible errors in your makefile.
=item --populate-bc-only
Don't import for the build cache. This is useful when you want to
donate targets to the cache, but you don't want to rely on the contents
of the cache (e.g. for mission-critical builds).
=item -q
=item --quiet
Don't print informational messages like "Scanning xyz.h" or "Loading
makefile /users/src/bob/funproject/Makefile".
=item -r
=item --no-builtin-rules
Don't load the default rule sets. If this option is not specified, and
the variable C<makepp_no_builtin> is not defined in the makefile, then a
set of rules for compiling C, C++, and Fortran code is loaded for each
directory.
=item -R dir X<-R>
=item --repository=dir X<--repository>
Specify the given directory as a repository (see L<makepp_repositories>
for details). Repositories are added in the order specified on the
command line, so the first one you specify has precedence. All files in
the directory (and all its subdirectories) are automatically and
temporarily linked to the current directory (and subdirectories) if they
are needed.
If you just specify a directory after C<-R>, its contents are linked into the
current directory. You can link its contents into any arbitrary place in the
file system by specifying the location before an equals sign, e.g, S<C<-R
subdir1/subdir2=/users/joe/joes_nifty_library>>.
=item -s
=item --silent
=item --quiet
Don't echo commands.
=item --stop
=item --stop-after-loading
After loading the top level Makeppfile, and any others explicitly or
implicitly (through dependencies from other directories) loaded from there,
makepp will stop itself (go to sleep). This happens before it analyzes
anything else. It will tell you the command needed to wake it up again. If
you do it in a Shell, you get the prompt and can then fore- or background it.
If you do it within an IDE, it'll just sleep, and you can awaken it from
another Shell.
The intention is that you can start makepp this way before you're finished
editing some files. Depending on your project structure and size, this can
allow makepp to get a headstart of many seconds worth of work by the time
you're done.
If you use C<prebuild> or C<$(make)> it will stop when it gets to that point,so it might not be so useful. Nor will it consider regeneration of
Makeppfiles, but this is not expected to happen frequently.
=item --symlink-in-repository-as-file
If a repository contains a symbolic link, then by default that symbolic link
is imported as a link, which is to say that the target of the imported link
need not be identical to the target of the symbolic link in the repository.
If the C<--symlink-in-repository-as-file> option is specified, then the
symbolic link is imported as its target file, which is to say that the imported
link points to the same target file as the symbolic link in the repository.
This is useful if the symbolic link in the repository was intended to have
the build-time semantics of a copy.
=item --traditional-recursive-make
This option is present to allow makepp to work with old makefiles that
use recursive make extensively. By default, recursive make isimplemented by a subprocess that communicates with the parent process;
the build is actually done by the parent process. This allows some of
makepp's nice features like repositories to work with recursive make
invocations. However, this technique will not work if you load more
than one makefile from the same directory, or if you use differentcommand line options on different invocations of recursive make. The
C<--traditional-recursive-make> option makes makepp do recursive makes
the same way as the traditional make, allowing more makefiles to work,
but then repositories and parallel builds do not work properly. This
option is rarely needed any more, and makepp will tell you if it runs
into a construct that requires it.
=item -v
=item --verbose
Verbose mode. Explains what it is trying to build, and why each file is
being built. This can be useful if you think a file is being rebuilt
too often.
This option actually takes what would be written to the log file and
displays it on the screen. It's usually easier to run makepp and then
look at F<.makepp_log>.
=item --version
Print out the version number.
=item --virtual-sandbox
Don't rewrite build infos of files that were not created by this makepp process.
This is useful when running concurrent makepp processes with overlapping
sandboxes, and you are certain that no two processes will attempt to build
the same target. Makepp will then refrain from caching additional information
about files that it reads, because there might be other concurrent readers.
=back
=head1 ENVIRONMENT
Makepp searches upwards for a file called F<.makepprc> when starting and again
after every C<-C> or C<-c> option. Each time it finds such a file, but only
once per file, it will read the file and parse it as possibly quoted options
on one or several lines. Unlike the option C<-A>, the options will be parsed
relative to the directory where the file resides.
Makepp looks at the following environment variables:
=over 4
=item MAKEFLAGS
Any flags in this environment variable are interpreted as command line options
before any explicit options. Note that the traditional make also uses this
variable, so if you have to use both make and makepp, you might want toconsider using C<MAKEPPFLAGS>.
=item MAKEPPFLAGS
Same as C<MAKEFLAGS> as far as makepp is concerned. If this variable is
not blank, then C<MAKEFLAGS> is ignored. Sometimes this is useful
instead of C<MAKEFLAGS> if you have to use both make and makepp, and youneed to keep the options separate.
=item MAKEPP_CASE_SENSITIVE_FILENAMES
Makepp will attempt to determine whether its default directory is case
sensitive by creating a file and then accessing it with a different
case. Usually this works fine, as long as all the files you're
accessing are on the same file system as your default directory, so you
should rarely need to use this option.If this variable is present in the environment, its value (C<0> or empty
string for false, anything else for true) will override makepp's choice. This
variable is mostly useful on Windows, if you want to override makepp's default
setting. If you don't treat filenames as case sensitive, then makepp converts
all filenames to lowercase, which causes occasional difficulties. (E.g.,
emacs may will open several buffers to the same file.)
Makepp does not currently support a build across several file systems,
one of which is case sensitive and the other case insensitive.
=back