The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.
Makepp, a build program which has a number of features that allow for reliable
builds and simpler build files, is a drop-in replacement for GNU make. It
supports almost all of the syntax that GNU make supports, and can be used with
makefiles produced by utilities such as automake. It is called makepp (or
make++) because it was designed with special support for C++, which has since
been extended to other languages like Swig or embedded SQL. Also its
relationship to make is analogous to C++'s relationship to C: it is almost
100% backward compatible but adds a number of new features and much better
ways to write makefiles.

Makepp works on Unix/Linux-like systems, Ebcdic-based emulations like BS2000
or z/OS and Windows.  It is written entirely in Perl.  It requires version 5.8
of Perl or newer.  It's distributed under the terms of the Perl Artistic
License or GPL 2 or newer, which means that it's freely available to anyone
for just about any purpose.

For the latest distribution, manual pages, and information about mailing
lists, please see the makepp home page, http://makepp.sourceforge.net.

Features:

o Makepp supports almost all makefile syntax that GNU make supports.
  Makepp is compatible enough with GNU make and stable enough to compile
  large packages, such as KDE 2.0.  (For details, see the manual section
  on old makefiles).

o Makepp automatically scans C/C++ sources for include files.  The
  implementation is flexible enough that support for other languages can
  be easily added.

o Makepp remembers the build command, and rebuilds if the command has
  changed, even if none of the files have changed.  This is useful if
  you change command line options (e.g., adding -DDEBUG or -g)--you
  don't have to do make clean.

o By default, makepp rebuilds if any dependency files have changed
  (even if they are still older than the target).  For example, if you
  replace a file with an older version, makepp knows to recompile.  This
  also means that makepp is not bothered by clock synchronization
  problems.  (If necessary, you can tell it to recompile only if the
  target is older than a dependency.)

o Makepp has a better system for handling makefiles spread across several
  directories.  makepp loads several makefiles simultaneously (keeping
  the variables and default directories separate), and it will realize
  automatically that a file needed by one makefile is built by a
  different makefile.  Recursive invocations of make are no longer
  necessary (but are still supported for backward compatibility).

o Makepp will not recompile if only comments or whitespace in
  C/C++ sources have changed.  This is especially important for header
  files which are automatically generated by other programs and are
  included in many modules.  Even if the date has changed because the
  file was remade, makepp won't recompile if the file hasn't changed.

o Makepp won't mix output from separate processes when running compilation
  commands in parallel.

o Makepp writes a log file explaining all of its build decisions,
  showing what each file depended on and what changed to cause each rule
  to be executed.  This makes debugging your makefiles much easier.

o Wildcards refer not only to files which already exist but to
  files which don't exist yet but which can be made.  Thus you can
  specify

    libmine.so: *.o

  and the compilation will work properly even if none of the
  .o files exist yet.

o Makepp can automatically separate your source and object directories,
  even if your makefile is not written that way.  (This is like VPATH
  but is completely transparent, even for include files.)  Makepp can
  also build separate copies of your program with different compilation
  options or on different architectures, automatically keeping the
  output files separate--you don't have to modify your makefiles at all.

o You can ask makepp to infer what object files are necessary for
  your program if your source files follow the simple convention that
  the implementation of all the classes and functions in a .h file is
  contained in a .cxx, .cc, .C, or .cpp file of the same name.  This can
  often avoid the use of .a files.

o Makepp won't be confused by multiple names for the same file.  It realizes
  that xyz.o, ./xyz.o, and ../objects/xyz.o are the same file, and if
  you load a makefile in a subdirectory, it will recognize that
  references in that subdirectory to ../xyz.o refer to the same file as
  xyz.o in the main build directory.  It also won't be confused by soft
  links in directory names.

o Makepp supports filenames with special characters like space or ":".  Just
  put any filenames with special characters in single or double quotes.

o Makepp supports more easily understood synonymns for the cryptic
  symbols $@, $<, $^, etc.

o You can define your own text processing functions in Perl if
  the default ones are not sophisticated or convenient enough.
  You can also embed Perl code to manipulate the make variables directly
  in your makefile.

Why not cons?  cook?  bake?  icmake?  jam?

These are good make utilities too, with some of the same features,
especially those relating to reliable builds.  I wrote makepp because
(at the time) cons wasn't flexible enough.

makepp is likely to work with existing makefiles, because it tries hard
to emulate all the features of the standard make implementations while
nonetheless being safer.  It has been tested successfully on several
large systems of makefiles, including large projects controlled by
autoconf and automake.  And you don't have to learn any new syntax or
write any new files to use makepp; you can probably use your old
makefiles (with possibly only minor modifications).  On the other hand,
you can take advantage of makepp's additional features to simply your
makefiles.