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