GNU Autotools is a suite of various task-oriented tools: automake, autoconf and libtool.
A few years ago, the autotools suite was fairly reliable, which led to a growth in its popularity. However, in recent years the current custodians of the suite have chosen to constantly change the syntax of autoconf's input scripts, making many unnecessary changes in the format of basic declarations.
The whole point of such tools is to automatically configure sourcecode for building on a wide variety of platforms, and in order for this to succeed it is imperative that the build tools themselves are stable.
* broken functionality (eg. glibtool on OS X)
Convert liboggz to build with each of the contenders.
Of course GNU Autotools is a complex and powerful set of tools, and everyone uses a slightly different subset of their functionality. My needs are geared towards building a C library and programs, and encompasses a fairly representative set of tasks for the majority of Free Software projects:
MIT license
SCons aims to throw away the entire build suite -- not just autotools, but also make, and includes inbuilt build caching like ccache.
SCons is used for such high-profile projects as Doom3 and blender.
However it's when you start introducing slightly more complex builds that it begins to get unwieldy: Construction Environments
supports parallel builds
pkg-config support env.ParseConfig('pkg-config --cflags --libs libxml')
Integrates with BitKeeper and legacy systems such as RCS, SCCS, CVS and Perforce to automatically fetch non-existent source files.
A Win32 Executable is available for which Windows users do not need to install Python.
SCons automatically builds for POSIX and Windows systems, and supports MS precompiled headers and MSVC++ external debugging information.
Has Precious similar to those in GNU Arch.
SCons can do autoconf-style TryLink (build a stub program to actually test symbol usage). This is a very useful feature. For example, when I began developing Sweep, the Ogg Vorbis libraries had only recently hit 1.0, and many distributions shipped slightly older versions. These were mostly compatible, apart from a simple API change where an argument had been added to a function -- a subtle difference which cannot be discovered by simply checking for the existence of the function. By using AC_TRY_COMPILE in the configure script, I could test which of these versions was in use by instructing it to try to compile 4 lines of source; my program would then call the function in different ways accordingly.
You can follow my implementation of SCons building support in liboggz at http://trac.annodex.net/browser/liboggz/branches/scons/
It took exactly 15 minutes to get to a point where SCons builds the main library. This was quite painless and took minimal configuration, and was certainly far simpler than setting up libtool.
I needed to write a python statement to determine byteorder; turned out to be really simple ("if sys.byteorder == 'big':") which demonstrates the power of using a real programming language, as such things are already built in.
After around 2 hours I was able to generate a full build of programs and libraries, with command-line options and byteorder checking.
Retrieving option keys wasn't easily documented : env.Dictionary() I only found this by reading the SConstruct file from Blender.
SCons has no default installation methods; such things must be hand-coded. Similarly, SCons has no way to create source tarballs or zip files for distribution.
SCons has no inbuilt concept of tests. I found a thread on Running unit tests which contained some pointers on how to construct methods to run a test suite. Doing so in a manner which is close to that of automake required a somewhat deeper understanding of SCons, and a little more python hackery. The result was quite simple, but certainly not as easy as it should be. IMHO a build tool should encourage best practices, and running a test suite is certainly part of that.
Perhaps what I like most is the notion of Builders, which always reminds me of Lemmings.
BSD license
PMK aims to replace autotools, and also includes builtin pkgconfig compatible checking of system dependencies.
2005 will be a year of mass migrations away from GNU autotools.
An interesting point of integration between build systems and version control systems. On the one hand, we have version control systems like GNU Arch and Darcs pushing the limits of decentralized, shared development. On the other we have these new build systems