makeppinfo man page on DragonFly

Man page or keyword search:  
man Server   44335 pages
apropos Keyword Search (all sections)
Output format
DragonFly logo
[printable version]

MAKEPPINFO(1)			    Makepp			 MAKEPPINFO(1)

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,  V: -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, 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).

       -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.20.3			  2012-02-07			 MAKEPPINFO(1)
[top]

List of man pages available for DragonFly

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net