This is the documentation of version 1.50. You may want the documentation of the stable version (2.0) or of the well tested 2.1 development snapshot or our homepage.

makeppinfo

What makepp knows about files

?: -?A: -A, --args-file, --arguments-fileF: -f, --forceH: -h, --helpK: -k, --keylist, --keysM: $MAKEPPINFOFLAGSQ: -q, --quietT: -t, --traverseV: -V, --version

makeppinfo option file ...

mppi option file ...

Makepp writes detailed information about the files it built and about their dependencies. This information is stored in the .makepp subdirectory along the file it pertains to. It has the form of key-value pairs. In some cases the value will again be a list of associated pairs, typically the signature and the file.

If both ENV_DEPS and ENV_VALS get displayed, they are merged into a two column table.

If both DEP_SIGS and SORTED_DEPS get displayed, they are merged into a two column table (in this order which gives a better layout). Each dependency has a SIGNATURE which is only timestamp,size, used only to check if the file must be rescanned. The interesting information is stored in some other key. The md5 signature in MD5_SUM, the smart c_compilation_md5 signature in C_MD5_SUM, shared_object in SHARED_OBJECT and verilog_synthesis_md5 in V_MD5_SUM.

These signature lists are the most frequent reason for rebuilding a file, so you might like to check, whether the signature stored for a dependency matches the current build_signature of that file. If the signatures and everything else matches, that is the basis for getting a file from (one of) your repositories or build cache if it is found there. The details depend on the applicable build check method,

This command is partially a makepp debug tool. The list of keys varies depending on which scanner, build check and signature was used. To fully understand the output, you may need to look at the source code. That said, there is also some generally interesting information to be gotten.

Valid options are:

-A filename
--args-file=filename
--arguments-file=filename

Read the file and parse it as possibly quoted whitespace- and/or newline-separated options.

-f
--force

Display info even when it is invalid because of inexistent or modified file.

-?
-h
--help

Print out a brief summary of the options.

-k list
--keys=list
--keylist=list

The list specifies one or more space separated Shell style patterns (with [xyz], ?, *, {a,bc,def}). Remember to protect these from your Shell by quoting. These are matched against the keys. Each pattern may be preceded with an exclamtion mark (!) or a caret (^) to exclude the matched keys from those selected before instead of adding them to the selection. If the first pattern starts with an exclamtion mark, it operates on all keys.

--keys='COMMAND CWD'        # How was this built and where (relative to file).
-q
--quiet

Don't list file and key names. Repeat to also omit warnings.

-t
--traverse

Also output the same information for each file in SORTED_DEPS (recursively if repeated).

-V
--version

Print out the version number.


EXAMPLES

Each build check method documents how to see what they base their decision on. Finding the paths of the dependencies is the same in all cases, so it is shown here. If you build to a different directory, finding the path of the inputs requires a translation. E.g.:

mppi -k'CWD SORTED_DEPS' obj/b.o
obj/b.o:
CWD=../src
SORTED_DEPS=
    b.c
    inc/b.h
    /usr/bin/gcc

CWD is the directory relative to file, from where it was built. That directory is the one from where all relative paths in SORTED_DEPS start. This means that under the same directory we have inputs src/b.c and src/inc/b.h and an output obj/b.o. From the viewpoint of b.o, the inputs are ../src/b.c and ../src/inc/b.h. It does not matter that we gave a relative path for b.o, the information shown would be the same, had we first changed to obj.


ENVIRONMENT

Makeppinfo looks at the following environment variable:

$MAKEPPINFOFLAGS

Any flags in this environment variable are interpreted as command line options before any explicit options. Quotes are interpreted like in makefiles.


Daniel Pfeiffer
Last modified: 2011-01-23