Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
MAKEPP_FAQ(1)			    Makepp			 MAKEPP_FAQ(1)

NAME
       makepp_faq -- Frequently	asked questions	about makepp

DESCRIPTION
       Here you	may find some points which are not obvious from	the rest of
       the documentation.  This	shows stumbling	blocks,	whereas	howto type
       questions will be found in the cookbook.

   Build Questions
       Why does	it run this rule 3 times?

       Gnu make	has no makepp style multi target rules.	 Instead it interprets
       this as a shortcut for three separate rules:

	   a b c:
	       echo $@
	       touch a b c

       However,	it doesn't check why a file is there.  If a file exists	(and
       is newer	than any dependencies) it is happy.  Whichever of the three
       files gets built	first, provides	the other two, so this behaves
       somewhat	like a multitarget rule	-- but can cause race conditions in
       parallel	builds.

       A similar rule might have been:

	   a b c:
	       touch $@

       Gmake indeed runs this one once per required file.  Without knowing
       what the	command	does (it might be a script which internally creates
       some files), the	two cases can't	easily be told apart by	makepp.

       So as a special compatibility fallback, if a multi target rule action
       mentions	only old style $@ and neither new style	"$(output)" nor
       "$(target)" nor their plural forms, it is treated as separate rules.
       This however means running it repeatedly, as makepp ignores randomly
       appearing files for which it has	no metadata.

       Why does	it complain that a created file	is phony?

       If you have a command that continues working asynchronously, after it
       came back with a	success	return code, makepp will notice	the promised
       file as missing and complain.  This can also typically happen on	some
       network file systems, which may physically write	only several seconds
       later.

       If you cannot evite such	an unsatisfactory situation, you can ask
       makepp to be sloppy about this check with the "--gullible" option.  But
       then the	next command which depends on the produced file	might still
       fail.

       Why does	it recreate files unnecessarily?

       I have observed this on NFS, where due to file attribute	caching	the
       timestamp of the	produced file was not yet the one the it finally had.
       On the next run makepp noticed the difference and considered the	file
       unduly modified.	 This got resolved with	a mount	option of
       "acregmin=0", making attributes visible immediately.

       This can	also happen with repositories, e.g. if someone else has	built
       in the repository with "umask 066" or using a compiler that bars	others
       from reading the	produced file.	This will also happen if either	the
       repository or your build	tree shares a common path prefix with some
       dependencies (e.g. /opt/repository and /opt/sometool, in	which case
       makepp will remember the	path once as relative, and once	as absolute,
       looking like changed dependencies.

   Miscellaneous
       Why does	makepp selectively detect dependencies?

       In this rule why	does makepp make output	depend on input1, but not on
       input2?

	   output:
	       zcat <input1 >output
	       zcat input2 >>output

       There are three levels to scanning.  The	first is the lexer, which
       tries to	understand the Shell part of the execution.  I.e. which
       commands	get called and what I/O	redirections take place.  This notices
       input1 and output (even if it had not been declared a target of this
       rule).

       The next	step are the command parsers.  Makepp has a few	for typical
       compilation commands.  These check the command line options to
       understand what the command will	do.  In	the process they pick up
       dependencies like libraries ("cc	-llib"), include paths ("cc -Idir")
       and input files.	 The task of a "zcat" parser would be to know that
       "-S" takes an argument, but all other non option	words are filenames
       (optionally suffixed by .gz), and that "--" ends	options.  Alas there
       is no such parser, no more than for hundreds of other commands.

       The third step for some languages is the	scanning of input files, to
       detect includes as further dependencies.	 This does not apply to	this
       example.

       How can I debug makepp?

       You can put "$(print )" around a	suspicious expression.	This returns
       the unchanged expression, while printing	it as a	side effect.

       You can dump the	current	directory's (multiply after "-C" if you	want)
       makefile	with the "--dump-makefile=file"	option,	to see how makepp sees
       it.

       Makepp writes a log of everything it does and why.  You can look	at
       that with makepplog, mppl or makeppgraph, mppg.

       Makepp records all it knows about a file, for reuse on the next run.
       Though it takes some understanding of makepp's internals, dumping it
       with makeppinfo,	mppi for one or	more files, usually gives a clue what
       is wrong.

       Is it safe to use?

       Yes, it will do exactly what your makefiles say (which many programmers
       find hard to understand,	since rule based inference is very different
       from most programming paradigms).

       And no, if you don't trust the makefiles	you got, definitely not!  A
       makefile	is a funny kind	of script, the purpose of which	is to run
       commands	that are expected to modify your file system.  Makepp has no
       means of	checking what they will	do.

       Worse, there are	execute	always syntaxes, which are performed even with
       "--dry-run" (which does not run the rules, but evaluates	everything
       else).  That might be something like this:

	   bad_boy := $(shell rm *)

   External tools
       Can I use cc -M or gcc -MM?

       The short answer	is yes.	 The long answer is that they have the
       advantage of knowing the	effect of even the last	weird compiler option,
       and sub-includes	hidden in some compiler	internal directory, where
       makepp only comes pretty	close.	The disadvantage is that they have no
       idea of the build rules,	so they	can not	reliably depend	on yet to-be-
       built files, which includes files to be fetched from a repository.  And
       they are	not extensible to other	languages, as makepp's scanner is.
       Usually you are at least	as well	off, not resorting to these tools.

       Nonetheless, some compilers can produce this as a by-product.  If you'd
       rather use this see :include.

       Can I use CCache, Compilercache or cachecc1?

       The short answer	is yes.	 The long answer is that these programs	need
       to repeat the work makepp does, to get a	reliable fingerprint of	files.
       With traditional	makes this even	comes too late,	because	those miss
       many situations calling for a recompilation.  With makepp it is just
       easier to use the built in build	cache, which has the added advantage
       that it can handle all kinds of files.

AUTHOR
       Daniel Pfeiffer (occitan@esperanto.org)

perl v5.32.1			  2012-02-05			 MAKEPP_FAQ(1)

NAME | DESCRIPTION | AUTHOR

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=makepp_faq&sektion=1&manpath=FreeBSD+13.0-RELEASE+and+Ports>

home | help