Eventually aims to be a complete solution for software configuration, building, installation and distribution.
Some vague principles: keep your build configurations as tiny as possible. Leverage/target existing build and package systems. Lots of features. Extensibility. Portability. Cross-language. Cross-project. Etc.
Current features:
This package also contains a patched version of googlecode_upload.py
that can use an alternate, simpler auth data file than subversion’s cached auth data (which is currently broken). This version uses a file ~/.googlecode.auth
(with permissions 600) containing your username and password on separate lines.
Say the directory ~/myapp/
contains two C++ programs: client.cc
and server.cc
. To build these with SimpleBuild, create a file called build
containing the following YAML data:
client:
srcs: [client.cc]
server:
srcs: [server.cc]
libs: [pthread, profiler]
Now running simple-build
generates a GNUmakefile
that can be used to compile both programs in a variety of ways. We could alternatively keep the source tree clean of generated files by changing to a different directory and running simple-build ~/myapp/build
.
The libs
field lists libraries that are to be linked with the application. simple-build
is also capable of inferring libraries by automatically determining the headers included by your source files and then mapping these onto library names.
The GNUmakefile
also contains a mechanism for automatically generating dependencies from your source files. This mechanism relies on gcc -M
and some GNU make
tricks. I also take other cues from Peter Miller’s excellent paper “Recursive Make Considered Harmful”.
This automatic dependency generation is also available for Java and Scala; the mechanism there relies on the compilers’ verbose output, and has only been tested with Sun’s javac
.
Planned features:
all
) to build only certain targets that the user is interested in (currently all configurations of all programs are built)The decision to write yet another build system was based on the empty-handed outcome of a long (and depressing) quest. Here are brief commentaries of some other build systems.
autotools: The de-facto standard for portable source distributions, but writing portable, meaningful configure.ac
scripts requires a lot of care, which doesn’t suit well the frequent one-off programs I write. Also, autotools
doesn’t do much for Java or Scala. The aspiration for SimpleBuild is to one day be able to generate autotools
inputs (as well as other kinds of software packaging).
Boost.Build: A system for building C++ projects. Can discover only transitive dependencies that can be found without relying on implicit locations (such as those that are found via gcc’s CPATH
, C_INCLUDE_PATH
, CXX_INCLUDE_PATH
, etc.). Contains a scripting language that I’m still learning, but for simple configs, the language is terse and appears nice. The community doesn’t seem to be as active as CMake’s.
GNU make
: Currently, SimpleBuild targets only make
.
ANT: A portable, “cleaner” version of make
. Where make
relies on shell commands for its actions, ANT relies on actions implemented in Java (either built-in or provided by extensions). Also, ANT does not by default (i.e., all targets are “phony”). It is also rid of other make
idiosyncracies (syntax, whitespace values, etc.).
Maven: Much more than a build system, Maven tries to cover everything related to the general maintenance of software with attention to cross-project maintenance, and is even a standard way of publishing and obtaining software. A number of plug-ins (also automatically obtained) take care of continuous builds, testing, and integration, all presented in a cohesive dashboard interface. It requires the project follow certain conventions (e.g. in file organization), but this turns out to be reasonable for most projects. Again, Maven is not as meaningful for one-off Scala scripts (Scala Maven tools do exist, BTW), but this is where I hope to take SimpleBuild
someday.
clump: A way to build C programs without any build configuration file whatsoever. The idea of automatic library inference via a header-to-library database came from here.
CMake: Cross-platform make
. Uses its own quirky scripting language and has quite a few features. Kind of ugly. As always, long-tail configurations are more painful. “Why the KDE project switched to CMake” is a nice article on CMake (vs. auto* and SCons). I should target this.
WAF: An even simpler/more barren build system. You actually write imperative scripts for each build you need. A bit scary.
DART: Somewhat like Maven but for C++, providing a tests/reports/dashboards for monitoring the status of projects. From the same people behind CMake.
SCons: For building C, C++, Java, and more. Very minimalistic in its approach, and imposes (even defines well) few abstractions. It doesn’t have many features.
buildr: A drop-in replacement for Maven written in Ruby. Supports Scala, apparently.
rake: SCons in Ruby.
rant: Ant in Ruby.
SAnt: Ant in Scala (abandoned).
Simple-Build is released under the GNU GPL3.
Copyright 2008 Yang Zhang.
All rights reserved.
Back to assorted.sf.net.