| MAKEPP_COMMAND(1) | Makepp | MAKEPP_COMMAND(1) |
makepp -- Command line syntax for makepp
?: -?, A: -A,
--args-file,
--arguments-file,
--assume-new,
--assume-old, B: -b,
--build-cache,
--build-check,
--build-check-method, C: -C,
-c, D: --defer-include,
--directory,
--do-build,
--dont-build,
--dont-read,
--do-read,
--dry-run,
--dump-makefile,
--dump-makeppfile, E: -e,
--environment-overrides,
--env-overrides, F: -F,
-f,
--file,
--final-rules-only,
--force-copy-from-bc,
--force-rescan, G: --gullible,
H: -h,
--help,
--hybrid,
--hybrid-recursion,
--hybrid-recursive-make, I: -I,
--implicit-load-makeppfile-only,
--include,
--include-dir,
--in-sandbox,
--inside-sandbox, J: -j,
--jobs,
--just-print, K: -k,
--keep-going, L: --last-chance-rules,
--load-makefile,
--load-makeppfile,
--log,
--log-file,
--loop, M: -m,
--makefile,
$MAKEFLAGS,
$MAKEPP_CASE_SENSITIVE_FILENAMES,
--makeppfile,
$MAKEPPFLAGS,
--md5-bc,
--md5-check-bc, N: -n,
--new-file,
--no-builtin-rules,
--no-cache-scaninfos,
--no-implicit-load,
--no-log,
--no-path-executable-dependencies,
--no-path-exe-dep,
--no-populate-bc,
--no-print-directory,
--no-remake-makefiles,
--no-warn, O: -o,
--old-file,
--out-of-sandbox,
--override-signature,
--override-signature-method, P: --populate-bc-only,
--profile, Q: --quiet, R: -R,
-r,
--recon,
--remove-stale,
--remove-stale-files,
--repository,
--rm-stale,
--root-dir,
--root-directory, S: -s,
--sandbox,
--sandbox-warn,
--sandbox-warning,
--signature,
--signature-method,
--silent,
--stop,
--stop-after-loading,
--stop-before-building,
--stop-on-race,
--stop-race,
--symlink-in-rep-as-file,
--symlink-in-repository-as-file, T: --traditional,
--traditional-recursion,
--traditional-recursive-make, V: -V,
-v,
--verbose,
--version,
--virtual-sandbox, W: -W,
--what-if
makepp [ option ... ] [ VAR=value ] [ target ... ]
mpp [ option ... ] [ VAR=value ] [ target ... ]
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
Valid options are most of the standard make options, plus a few new ones:
For example,
% cc -g -DSPECIAL_DEBUG -c x.c -o x.o # Special compilation by hand
% makepp
cc -g -O2 -c x.c -o x.o # Makepp just overrode your compilation here!
cc x.o y.o -o my_program # Relinks.
% cc -g -DSPECIAL_DEBUG -c x.c -o x.o # Do it again.
% makepp --dont-build x.o # Tell makepp not to rebuild x.o even if it wants to.
cc x.o y.o -o my_program # Now it relinks without recompiling.
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 "Target-specific assignments" in makepp_variables for an easy way of doing this.
If you put a RootMakeppfile(.mk) at the root of your build system, that directory and everything under it defaults to "--do-build", while the overall root of your file system defaults to "--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 explicitly pick them up with "load_makefile" statements in one of the makefiles within your tree.
You may have one 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 RootMakeppfile(.mk) in nested directories, avoiding funny effects that tend to arise when you accidentally call "makepp --repository" again in a subdirectory. These effects include duplicate rules through duplicate sources, or eternal build cache reimports because cached files have the right signatures but the wrong relative pathes.
Override "--dont-build" for the specified file or directory. If you have a 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 "--do-build". If you specify "--do-build" for a file or directory under a RootMakeppfile(.mk), without "--dont-build" for a higher directory, then the root (and all else under it) of your build system defaults to "--dont-build".
To resolve conflicts between "--dont-build" and "--do-build", the one with the most specific path takes precedence regardless of order. If the same path is specified with both "--dont-build" and "--do-build", then the rightmost one wins.
The options "--dont-build" and "--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 potentially unsafe speedup methods.
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 contains both the include statement and the interpolated file.
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", "-f", "-F", "-I" and "-R" options are specified, you can make targets relative to the current directory like this:
makepp -F /foo/bar -C . mytarget
The first two (RootMakeppfile) are special (whether given explicitly or found implicitly). There must be at most 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.
If you do use this option, you will get log files in the each directory the fall back occurred in. To get rid of only them use "makeppclean --logs --recurse" or "mppc -lr".
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, and stderr messages will usually appear before stdout stuff, differing from terminal output.
Native Windows Perls (i.e. Strawberry and ActiveState), because they do not support the Unix fork/exec paradigm, do not allow this option (Cygwin works fine!). As a partial replacement, you can use the --sandbox option there, though this is far less comfortable.
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. Then every time you can edit more and awaken it again, unless you change something in your Makefile, which will go unnoticed until you start a new instance of makepp. The same applies to repositories, which must never change while makepp is running.
If you use "prebuild" or "$(make)", on the first round it will stop when it gets to that point.
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 "@" or "noecho" are printed after the "@" or "noecho" is stripped off. However commands prefixed with "+" should be executed, but currently are not.
Warning: The commands that makepp executes with "-n" are not necessarily the same thing it will do without "-n". File signatures do not change at all with "-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 .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 <http://cproto.sourceforge.net/> for how the "cproto" application works or <http://www.lemoda.net/c/cfunctions/> for the similar cfunctions).
prototypes.h : *.c
cproto $(CPPFLAGS) $(inputs) > $(output)
Then each .c file will include 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. You don't even have to declare the dependency of your .o files on this one -- makepp will see the include statement and automatically see if it needs to (re)run cproto.
Now suppose you change just one .c file. What happens when you run makepp with "-n" in this case is that it realizes that prototypes.h needs to be remade. In all probability, remaking prototypes.h 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 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 prototypes.h will also have to be recompiled. Thus in this example, changing one .c file will cause "makepp -n" to think that every single .c file needs to be recompiled, even though most likely the regular 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) # Hacked technique not necessary for makepp
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 "makepp -n": it is not known whether the date on prototypes.h changes unless the command is actually run, so "makepp -n" cannot possibly be 100% accurate. (Note that using the traditional "make -n" will also have exactly the same problem on this example.)
"makepp -n" should always print out more commands than a regular invocation of 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.
This is useful for programs such as grep and diff, which always do basically the same thing even if their implementation changes, though you're better off using the builtin commands for grep. You may also need this for repositories on NFS clusters, where the same commands might not have the same timestamp everywhere, causing unnecessary rebuilds depending what machine somebody works on.
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 --dont-read. See partitioning into sandboxes.
If you just specify a directory after "-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, "-R subdir1/subdir2=/users/joe/joes_nifty_library".
For example, assume that there is an x.c file that looks like this:
#include "x.h"
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, x exits with status 2, but if you build while the old ./x.h file still exists and you don't specify "--rm-stale", then x exits with status 1, because the include directive picks up the stale generated header file.
If you build with "--rm-stale", then ./x.h is removed, and the result is the same as that of a clean build, which is almost always a good thing.
Note that if you build in a repository, you have to give this option there first, because the importing makepp doesn't know what might be stale in the repository.
Legacy makefiles sometimes put the rule to generate an include file after the include statement. Mpp works around that like gmake, by reloading at the end of the makefile if needed. But this means on a rebuild it looks stale at the point where it is needed, and will be deleted. Therefore this option turns off this kind of reloading.
"--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.
If you do use this option, you will get log files piling up in the various directories this changes to. To get rid of only them use "makeppclean --logs --recurse" or "mppc -lr".
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 the output of makepplog, which allows various selections and some rewriting.
Makepp searches upwards for a file called .makepprc when starting and again after every "-C" or "-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 "-A", the options will be parsed relative to the directory where the file resides.
Makepp looks at the following environment variables:
Note that the traditional make also uses this variable, so if you have to use both make and makepp, you might want to consider using "MAKEPPFLAGS".
If this variable is present in the environment, its value (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 well, if one is case sensitive and the other case insensitive.
| 2016-11-28 | perl v5.24.1 |