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

FreeBSD Manual Pages

  
 
  

home | help
MAKEPP_BUILD_ALGORITHM(1)	    Makepp	     MAKEPP_BUILD_ALGORITHM(1)

NAME
       makepp_build_algorithm -- How makepp executes a makefile

DESCRIPTION
       Makepp's	internals differ from the standard Unix	make in	fundamental
       ways.  This page	describes the different	philosophy in detail.

   Reverse vs. forward inference
       Makepp works in the opposite direction from the standard	Unix make.
       Traditional Unix	make is	given a	target to build, and then it finds a
       rule which matches the characters in the	target filename.  If the
       target is older than any	of its dependencies of the rule, then it is
       rebuilt.

       For example, consider this pattern rule:

	   %.o:	%.cxx
	       $(CXX) $(CXXFLAGS) -c $(input) -o $(output)

       When make realizes it needs to make a file called "xyz.o", it searches
       through its list	of pattern rules until it sees that "xyz.o" matches
       the pattern "%.o", and then it applies this rule.

       Makepp works in the opposite direction.	It first computes all files
       that it can possibly build by applying rules that match the characters
       in the dependency filenames.  Then when it needs	to build a file, it
       simply looks to see if it's one of the files that it knows how to
       build.  The list	of known files is stored based on the absolute
       filename.

       When makepp encounters the above	pattern	rule, it searches for all
       files in	the directory matching the pattern "%.cxx" (i.e., "*.cxx").
       For each	of these files,	it then	remembers that it can produce the
       corresponding ".o" file.	 If subsequently makepp	discovers that it can
       make another ".cxx" file	that doesn't currently exist, this rule	will
       also be applied and the corresponding ".o" file will be marked.

       This might seem somewhat	inefficient, but it turns out not to be	that
       slow in most cases, and it is often true	that virtually all the files
       that can	be built are in	fact built.  And knowing the complete list of
       files that can be built has several advantages:

          Wildcards can match files which don't exist yet but can be built.

          Header  files  which	have been detected by the automatic dependency
	   scanner don't have to exist;	 makepp	 knows	where  they  will  be.
	   (Most other solutions to this problem assume	that any headers which
	   don't exist yet are in the current directory.)

          Repositories	 are  much  simpler  to	 implement  since makepp knows
	   beforehand what files it can	make.	(See  makepp_repositories  for
	   details.)

          It  is  possible  to	determine easily which files can be built (see
	   the "$(only_targets )" function.

          Makepp's  "$(infer_objects)"	 function  is  greatly	simplified  by
	   knowing what	objects	are available.

   Files vs. textual patterns
       Makepp  associates  build commands with a target	file, not to a textual
       pattern for a filename.	It is  therefore  not  confused	 by  different
       names  for  the	same  file.   Thus, for	example, makepp	will know that
       "./xyz" and and "xyz" are the same file,	whereas	other  make  utilities
       may not.

       This  is	 particularly  important  because  (unlike  the	standard make)
       makepp loads makefiles from different directories.  In  order  for  the
       makefiles  to be	relatively independent,	with no	special	position given
       to a top-level makefile,	each makefile refers to	all files relative  to
       its  own	 directory.  Thus if you load a	makefile from the subdirectory
       "other_stuff", and that makefile	refers to "../xyz", makepp will	 again
       realize	that  it's the same file referred to above.  (It also won't be
       confused	by soft-linked directory names.)

   Stored build	information
       Makepp stores much more information about  each	file  that  it	builds
       beyond  just  the date stamp (which is all that the standard make cares
       about).	This information includes:

          The signature of this file on the last build, so  we	 know  if  the
	   file	itself has changed.

          The	names  of  each	 dependency  file, including include files and
	   other files inferred	automatically.	If  this  list	changes,  then
	   makepp assumes it needs to rebuild.

          The	signature  of  each  dependency.   This	 way,  makepp knows to
	   rebuild not only when the dependencies are newer than  the  target,
	   but	when  they  change at all.  This also makes it possible	to use
	   other kinds of signatures, such as cryptographic checksums,	rather
	   than	the file date.

          The entire build command (and its cwd).  This way if	you change the
	   build  command (e.g., change	the compiler options), makepp knows to
	   rebuild even	if the files themselves	haven't	changed.

          The architecture.  If you have compiled your	program	on  Linux  and
	   then	 switch	 to  Solaris,  makepp automatically knows to recompile
	   everything.

       Makepp makes a subdirectory in every directory that it  touches	called
       ".makepp".  The build information for a file filename in	a directory is
       stored  in  .makepp/filename.  If you delete this subdirectory or alter
       the files, makepp will rebuild all affected files.

   Implicit loading
       If makepp is trying to build a target in	a directory and	doesn't	have a
       rule for	it yet,	or if it is looking for	files matching a wildcard in a
       directory, it will look in that directory  to  see  if  a  makefile  is
       present.	 If so,	the makefile will be loaded automatically.

       This  means that	you usually don't have to tell makepp explicitly where
       to find makefiles--all you have to do is	to reference a file in another
       directory, and makepp will automatically	figure out how to build	it.

       Implicit	loading	will occur only	if the directory is writable  to  you.
       Thus  if	 you  want  to	prevent	makepp from trying to build a bunch of
       things that never change, simply	make the directory read-only.

       Implicit	loading	 will  not  occur  if  you  are	 in  a	tree  under  a
       RootMakeppfile(.mk)  and	 the  other makefile is	outside	that tree.  If
       you do want this	once, you can give a "--do-build=/" option to  makepp,
       to  make	 everything  outside  the  tree	buildable.  If you always want
       this, you can put a "load_makefile" statement somewhere within the tree
       to explicitly connect it	to the tree.

       If implicit loading gets	in your	 way  (i.e.,  makepp  loads  too  many
       makefiles  and  it wastes time, or else you really don't	want it	to try
       to rebuild all the stuff	described in the makefiles), you can  turn  it
       off  for	 all  directories  using  the "--noimplicit_load" command line
       option, or you can turn it  off	for  selected  directories  using  the
       "no_implicit_load" statement in your makefile.

perl v5.36.3			  2012-02-07	     MAKEPP_BUILD_ALGORITHM(1)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=makepp_build_algorithm&sektion=1&manpath=FreeBSD+Ports+14.3.quarterly>

home | help