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)

perl v5.24.1                                       2016-11-28                                      MAKEPPINFO(1)