Chapter 2. Building and Installing Abuild

2.1. System Requirements

You may always find the latest version of abuild by following
the links on abuild's
website. To use abuild, the following items must be
available on your system:

GNU
Make version 3.81 or higher is required
if you are building any build items that use GNU
Make as a backend. This would include
platform-independent code and C/C++ code, but not Java code.

A Java 5 or newer Java SDK is required if you are going to use
abuild to build Java code. Abuild is known to work with
OpenJDK 1.6.

Apache
Ant version 1.7.0 or newer is required if
you are building any Java code. If you are using abuild's
deprecated xml-based ant framework, then you also need ant-contrib
version 1.0.b3 or later installed in either ant's or abuild's
lib directory.

Perl version 5.8 or
newer is required if you are performing any GNU Make-based
builds.

Perl version 5.8 or newer and qtest version 1.0 or
newer are required if you are using the qtest automated test
framework. Abuild's own test suite uses qtest. Note also
that qtest requires GNU
diffutils. Any version should do.

In order to use abuild's autoconf support, you need autoconf
version 2.59 or newer, automake
version 1.9 or newer. These are also required for abuild's
test suite to pass since the test suite exercises its autoconf
support.

If you are planning on building any GNU Make-based build items
on Windows, Cygwin
is required. For a Java-only abuild installation on Windows,
Cygwin and Perl are not required. It is hoped that a future
version of abuild will not require Cygwin. For details on
using Cygwin with abuild, please see Section 2.4, “Additional Requirements for Windows Environments”.

To build abuild, you must also have version 1.35 or newer of
boost. Abuild uses
several boost libraries, including regex, thread, system,
filesystem, and date_time as well as several header-only
libraries such as asio, bind, and function. Abuild is known to
buildable by gcc and Microsoft Visual C++ (7.1 or newer), but it
should be buildable by any compiler that supports boost 1.35. In
order for shared library support to work properly with gcc, gcc
must be configured to use the GNU linker.
[3]
Abuild itself contains C++ code and Java code, so all the
runtime requirements for both systems are required to build
abuild.

In order to build abuild's Java code, which is required if you
are doing any Java-based builds, you must have at least version
1.5.7 of Groovy.
It is recommended that you have at least version 1.6.0. It is
not required that you have Groovy to run
abuild because abuild includes an embedded version of the
Groovy environment, but a full installation of Groovy is required
in order to do the initial bootstrapping build of abuild's Java
code.
[4]

As of abuild version 1.1.0, abuild is known to work with
Groovy versions 1.6.7 and 1.7-RC-1, which were the latest
available versions at the time of the release. Upgrading
abuild's embedded version of Groovy is as simple as just
replacing the embeddable Groovy JAR file inside of abuild's lib
directory. Just delete the old one and copy the new one in.
abuild will automatically find it even though its name will
have changed to include the later version number. Ideally, you
should also rebuild abuild's java support from source and rerun
abuild's test suite just to be sure abuild still works
properly with the latest Groovy.

Since abuild determines where it is being run from when it is
invoked, a binary distribution of abuild is not tied to a
particular installation path. It finds the root of its
installation directory by walking up the path from the abuild
executable until it finds a directory that contains
make/abuild.mk. This makes it easy to have
multiple versions of abuild installed simultaneously, and it
also makes it easy to create relocatable binary distributions of
abuild.

Abuild itself does not require any environment variables to be
set, but ant and/or the Java
development environment may. If you have the
JAVA_HOME and ANT_HOME environment
variables set, abuild will honor them when selecting which copy
of java to run and where to find the ant JAR files. Otherwise,
it will run java and
ant from your path to make those
determinations. Although abuild is explicitly tested to work
without either ANT_HOME or
JAVA_HOME set, if any Java builds are being done,
abuild will start up a little more quickly if they are set. As
many other applications expect these to be set, it is recommended
that you set JAVA_HOME and
ANT_HOME. When abuild invokes Java for any of
the Java-based backends, it will automatically add all the JAR
files in $ANT_HOME/lib to the classpath as
well as all JAR files in abuild's own lib
directory. Abuild includes a copy of Groovy's embeddable JAR
in its own lib directory. You can copy
additional JAR files into lib as well, but
if you do so, just remember that those JAR files will not
automatically be available to users whose abuild installations
do not include them.

As you begin using abuild, you may find yourself generating a
collection of useful utility build items for things like specific
third-party libraries, external compilers, documentation
generators, or test frameworks. There is a small collection of
contributed build items in the
abuild-contrib package, which is available
at abuild's web
site. These may have additional requirements. For
details, please see the information about
abuild-contrib on the website.

[3]
The only reason for the GNU linker requirement is that abuild
currently knows about -fPIC. It would be
better to have a more robust way of configuring flags for
position-independent-code, but it's not clear how to do this
without replicating all the knowledge built into
libtool or having some autoconf-like
method of configuring abuild at runtime.

[4]
Besides, every Java programmer should have a copy of Groovy
installed!