/quagmire

Automatically exported from code.google.com/p/quagmire

Primary LanguageMakefile

The goal is to replace at least automake and libtool with GNU make
macros.  Ideally we'll also replace most of configure -- configure
itself has to remain, to pick install directories and the like, but
most of its checks should be done in the Makefile.


Use the AM_QUAGMIRE macro in your configure.ac to do the work needed
for Quagmire.  Currently this emits a '.quagmire/variables.in' file
which contains all the variable settings (AC_SUBSTs) found by
configure. This macro also emits a Makefile in the build directory.

Your part of the build is written a bit like automake input.  Your
package should have a file named "Quagmire.mk" -- this is actually a
Makefile fragment.  Special variables in Quagmire.mk are recognized
and turned into rules.

One general rule in Quagmire is that if there is a simple, generic GNU
make way to do something, then we don't need special support for it.
This leads to many differences from the way that Automake does things.
For instance, in Automake there is a separate quux_CFLAGS variable for
an aggregate.  In Quagmire, you would instead use a target-specific
CFLAGS assignment.


Like Automake, Quagmire uses "primaries" with prefixes indicating
install directories.  An install directory variable is any variable
ending in "dir"; the standard ones are all pre-defined.  The primary's
prefix is the name without the "dir", e.g. for $(bindir) use 'bin'.
The special prefixes check and noinst are recognized.

Currently handled primaries:

_PROGRAMS - a list of the names of programs
  Each program can have several attributes.
  The attributes of a program are specified in variables named
  after the program.  Unlike automake, the given name of the program
  is used -- it is not rewritten.

  The defined attributes are:

  _SOURCES  all the source files.  headers are ignored.  other files
  are compiled into objects and linked in

  _LINK  the linker to use; the default is $(LINK.cc) if there are any
  C++ sources in the program, $(LINK.c) otherwise.

  _OBJECTS  the object files.  the default is computed from _SOURCES
  _EXTRA_OBJECTS  if you don't specify _OBJECTS you can specify extra
  objects using this.  (This may be bogus)

  _LIBS the libraries to link in

  _CONFIG_HEADERS the config.h headers used by this program

  _INSTALLNAME the name of the program when it is installed.  The
  default is the name of the program as it is built.

  _PACKAGES.  The value is a package specification to be passed to
  pkg-config.  Using this automatically adds the appropriate values to
  _CFLAGS, _CXXFLAGS, and _LIBS for this target

_LIBRARIES

  Static libraries, used like PROGRAMS.

  $(ARCHIVE) is used to build; defaults to $(AR), which defaults to 'ar'

  A library is similar to a program in some ways.  Derived variables
  which are the same: _OBJECTS, _EXTRA_OBJECTS, _CONFIG_HEADERS,
  _INSTALLNAME, _PACKAGES

_SHARED_LIBRARIES

  Also similar to PROGRAMS.

  Adds -fPIC to CFLAGS and CXXFLAGS
  Note that if you use a source in both a program and a shared
  library, confusion may result.  (This needs a real fix)

  Derived variables which are the same: _OBJECTS, _EXTRA_OBJECTS,
  _CONFIG_HEADERS, _INSTALLNAME, _LINK, _PACKAGES

A config header is built up by running tests, like autoconf
Currently a config header has two defined sub-variables:

  _FUNCTIONS: list of functions to check for.  A link test is done and
  the config header will define HAVE_FUNCTION if function is found.

  _HEADERS: list of headers to check for.  A compile test is done and
  the config header will define HAVE_FILE_H if the header is found.

  Example:

      program_CONFIG_HEADERS = config.h
      config.h_FUNCTIONS = strcmp strdup
      config.h_HEADERS = string.h sys/types.h

_DATA and _SCRIPTS

  Install data or scripts.  There is no difference right now; this is
  a bug in that scripts should be made executable when installed.

      data_DATA = file
      bin_SCRIPTS = sh-script

DejaGNU

  You can run a dejagnu test suite by setting DEJAGNU_TEST_DIR to the
  name of the subdirectory holding the testsuite.  This must be
  relative to the project base directory.

  You can override DEJATOOL if you have multiple tools to check.  The
  test suite for each tool can be run in parallel; they are all run in
  the same directory, so beware.


Features of automake that are handled:
  'clean' family of targets
  dependency tracking
  install, including DESTDIR, install-data, install-exec
  uninstall
  TAGS
  dist_ and nodist_ prefixes

Features of automake that are not handled:
  See TODO

Features we can have that are hard to do in automake:
  A verbose setting for builds
  We could echo "linux kernel"-like output: "CC foo.c" ...
  by having a variable set on the command line to choose output style
  ... we already do something here; if you use 'make -s' you will see
  much less output than what automake generates