NAME

       makeppinfo -- What makepp knows about files

DESCRIPTION

       ?: -?,  A: -A,
         --args-file,
         --arguments-file,  D: -d,
         --dates,
         --decode-dates,  F: -f,
         --force,  H: -h,
         --help,  K: -k,
         --keylist,
         --keys,  M: $MAKEPPINFOFLAGS,  Q: -q,
         --quiet,  T: -t,
         --traverse,  U: -u,
         --unremembered,  V: -V,
         --version

       makeppinfo option [file ...]

       mppi option [file ...]

       Makepp remembers detailed information about the files it scanned and/or built.  For the
       built files it remembers everything that was relevant, which includes 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.  For
       dangling symlinks, instead of the linkee's signature, the link's own signature is
       determined in this way, and a 0 prepended to mark this special case.  The interesting
       information is stored in some other key, for the built in signatures as follows:

       •   "C_MD5_SUM" for "C" or "c_compilation_md5"

       •   "MD5_SUM" for "md5"

       •   "SHARED_OBJECT" for "shared_object"

       •   "V_MD5_SUM" for "verilog_synthesis_md5"

       •   "XML_MD5_SUM" for "xml"

       •   "XML_SPACE_MD5_SUM" for "xml_space"

       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.

       You will encounter two kinds of signatures: simple ones consist of two comma separated
       numbers, which are the timestamp in file system format (seconds since 1970) and the size.
       For some files makepp will additionally have the relevant smart signature which is a
       base64 encoded (letters, digits, slash and plus) MD5 sum of the plain or digested file
       contents.

       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.

       -d
       --dates
       --decode-dates
           In the simple signatures prepend the 1st number, the raw date-time, with its human
           readable form in parentheses.

       -f
       --force
           Display info even when it is invalid because of inexistent or modified file.  In this
           case the key "SIGNATURE" is replaced by "invalidated_SIGNATURE" and the value
           indicates in parentheses that the file was deleted or what signature the file now has.

       -?
       -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 exclamation 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 exclamation mark, it
           operates on all keys.

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

           If you want only filenames (useful with "-t|--traverse") select an inexistent key like
           "none".

       -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).

       -u
       --unremembered
           Traverse dependencies of the given files, but instead of showing their info, from all
           the involved directories list only those files not remembered for these targets.  The
           idea here is to help you spot no longer needed files.  Somewhat surprisingly this will
           include the Makefiles from those directories, because these are mostly not a
           dependency.

           Giving this option twice will also go to far away directories which are not output
           relatively, like /usr/include.

       -V
       --version
           Print out the version number.

EXAMPLES

   General
       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 relative
       to CWD.  E.g. either short or long form:

           makeppinfo --keys='CWD SORTED_DEPS' obj/b.o
           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.

   The reason for a rebuild
       In some cases makepp may be repeatedly rebuilding a seemingly up to date file.  If
       "makepplog" does not help here, this command gives you the exact state of affairs:

           makeppinfo --traverse somefile
           mppi -t somefile

       When this reproducibly happens, issue this command before and after, and compare the
       outputs.  The things that differ are the reason of the rebuild.

   Proving Consistency
       Sometimes you will change your Makefiles and wonder if they still do the same thing.
       Here's a command that tells you exactly how makepp built somefile:

           makeppinfo --traverse --traverse --keys='CWD COMMAND' somefile
           mppi -ttk'CWD SORTED_DEPS' somefile

       This will recursively traverse over all dependencies of somefile and tell you in which
       directory it issued which command.  By running this after the old and after the new build
       and comparing the outputs, you can see what changed.

       The same works for testing a new version of makepp, though some older versions would
       handle whitespace in command continuation lines differently, and there was a bug in sort
       order, which can make the files come out in a different order.  If this is the case for
       you, let the Shell assemble the sorted arguments:

           makeppinfo --keys='CWD COMMAND' `makeppinfo --traverse --traverse --keys=none somefile|tr -d :|sort`
           mppi -k'CWD SORTED_DEPS' `mppi -ttknone somefile|tr -d :|sort`

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.

AUTHOR

       Daniel Pfeiffer (occitan@esperanto.org)