Appendix A. Release Notes

This table includes a list of user-visible changes or changes to
the documentation broken down by the specific release in which
they were entered. This can help get you “caught up”
if you are upgrading from an older release.

Note

If you are interested in seeing a summary of all the changes made
between versions 1.0 and 1.1 of abuild, please refer to Appendix B, Major Changes from Version 1.0 to Version 1.1. You can also get this
information from the release notes, but the information is
presented there in a more compact and organized fashion.

1.1.6: June 30, 2011

Bug Fixes

The verify-compiler command used for
testing your own compiler plugins did not work with nested
platform types. Nested platform types were added to abuild
in version 1.1.5, and compiler plugins worked with them; it
was only the verify-compiler command
itself that was broken.

When using qtest, the test-only target
no longer depends on the all target.

When dependencies are duplicated and platform
specifications are associated with at least one of the
dependencies, it is reported as an error. In the past, the
last platform specifier given would silently be used over
others, which could lead people to a false sense of
security if they were trying to declare a dependency on two
different platform types.

Enhancements

Duplicated dependencies and duplicated tree dependencies
are now reported as warnings.

New variables ABUILD_TRAITS and
abuild.traits are available to make and
groovy (respectively) backends that indicate which traits
are declared for the current build item.

A new interface variable,
SYSTEM_INCLUDES has been added. For
compilers that support it, any include directory that
starts with any of the values in SYSTEM_INCLUDES will be
specified to compiler with a flag that indicates that it is
a system include directory. For details, see Section 17.5.2, “Interface Variables for Object-Code Items”.

1.1.5: February 18, 2011

Enhancements

When abuild is run with the -k flag, the
condition of a particular item not being able to be built
on a particular platform because a dependency can't be
built on a compatible platform now causes a failure of only
that item on that platform rather than causing a failure of
the entire build.

The skip platform selector may now be used
without a platform type qualifier to prevent default
selection of any platform in any object-code platform type.
See Section 24.1, “Platform Selection” for details.

The build-also key has been enhanced
to allow specification of trees to build in addition to
items. It also allows options to be added to the
build-also items to further refine
what is built. The result is that anything can be built
from the command-line using build sets (except for the
regular expression pattern build set), and more, can now be
specified in a build-also key. This
enables much greater flexibility in creating project-level
top-level build items. For details, see Section 9.3, “Using build-also for Top-level Builds”.

Miscellaneous Changes

Minor tweaks were made to abuild's code and test suite to
enable it to be built with Visual C++ 2010 and boost 1.43.

The embedded version of Groovy has been updated to 1.7.8.

Bug Fixes

A bug to the groovy backend that prevented relative
directories from working properly when assigned to
java.dir.src and similar variables has been fixed. Thanks
to Brian Reid for the report, test case, and proper
diagnosis for the problem.

1.1.4: February 17, 2011

This release was not made publicly. It was basically what
1.1.5 is except that it had a logic error that rendered it
inoperative under certain conditions. The problem was caught
moments after internal release but prior to public release.

File-specific variables for XCPPFLAGS,
XCFLAGS, and
XCXXFLAGS were referenced in a manner
that prevented them from being properly expanded. They are
now properly expanded, so their values may include
references to other variables.

Miscellaneous Enhancements

The codegen-wrapper command now accepts
the --normalize-line-endings flag, which
tells it to disregard differences in line endings when
checking cached files to see whether their sources have
changed. Thanks to Jeremy Trimble for the suggestion.

When a platform plugin's list_platforms
script had Windows-style line endings, abuild (or, more
accurately, the underlying system) would produce a
confusing error message when trying to execute the script.
On non-Windows systems, abuild now explicitly calls your
attention to the incorrect line endings if
list_platforms fails.

The first line of output produced by the processing of any
build item now always includes an indication of the build
item name and output directory. In prior versions, there
were certain rare instances in which this would not
happen. For example, if an interface-only build item
depended on two other items whose
Abuild.interface files declared
conflicting variables, abuild would complain about the
conflict and indicate where it occurred, but it would not
provide any hint as to what build item caused the two
interface files to be loaded together. Now abuild will
always indicate which build item is responsible for causing
the problem to be detected.

When a platform selector specifies a platform type,
platform, compiler, or option specification that doesn't
match any items anywhere in the entire forest, abuild now
reports that as an error. It remains (and must remain)
perfectly normal for platform selectors to apply to only a
subset of the trees or items in a forest since most plugins
only apply to subsets of the forest. The previous behavior
of ignoring invalid platform types in platform selectors
was intended to allow the same platform selectors to work
across multiple forests, but in practice, having abuild
tell you about potential typos in platform selectors is
much more important functionality, and it's not really
practical to use the same platform selectors across
multiple forests in general anyway.

Documentation Changes

New help topics, make and
groovy, provide brief reminders of
things you can do in Abuild.mk and
Abuild.groovy files or local rules
files that they reference.

Fix errors in documentation for global plugins and platform
selectors.

Create new section on capturing and parsing abuild's
output.

1.1.2: April 16, 2010

Java Backend Implementation Changes

A minor improvement has been made to how abuild
communicates with its java backends. This is not a
user-visible change, but should eliminate any possibility
of protocol errors between abuild and its backend. This
problem has never been reported in production, but there
was a race condition under which it was possible.

Abuild invokes the JVM that runs the Java backends with a
parameter that sets the maximum PermGen space to 200
megabytes, overriding the default of 64 megabytes. This
should hopefully eliminate the out of memory problems that
are sometimes encountered with large builds.

New command line arguments --jvm-append-args
... --end-jvm-args and --jvm-replace-args
... --end-jvm-args have been added to provide
finer control over how the JVM that runs abuild's java
backends is invoked. These options are intended for use in
debugging abuild. If you have to use them to make your
build work, you should submit a bug report with the
details.

1.1.1: March 1, 2010

Bug Fixes

The Groovy-based Java backend was separating elements of
the manifest classpath with the path separator rather than
a space character. Thanks to Brian Reid for the fix.

Fix threading error in the Groovy backend that could, on
very rare occasion, cause a crash with multithreaded
builds. Thanks to Katie Outram for observing and reporting
the problem.

The Groovy backend was not including the
classes directory in the compile-time
classpath. This prevented java and groovy compiles in the
same build item from being able to see each other's
classes.

Other Changes

For compatibility with abuild 1.0 and to reduce warnings
with ant version 1.8.0, the Groovy backend sets
includeantruntime to
false by default in the
javac task. This can be overridden by
setting the java.includeAntRuntime
parameter in Abuild.groovy.

Minor fixes were made to abuild's ant backend to make it
work properly with ant version 1.8.0. Due to a bug in ant,
abuild's test suite may fail in spite of proper
operation. For details, please see ant
bug 48746 for details.

Minor fixes were made to abuild's build so that it works
properly on systems that require special arguments to use
pthread.

A new build set descdeptrees has been
added. This is the intersection of desc
and deptrees. It does what
desc did in abuild 1.0 and was added
just so that there was a 1.1 equivalent to abuild 1.0's
desc build set. Most users will never
need to use this build set.

Environment variable references in interface files may now
be specified with defaults. To do this, use
$(ENV:VARIABLE:default-value). The
default-value portion of the
variable reference may not contain spaces or parentheses.

Command line parameters may now also be referenced from
interface files. To do this, use
$(PARAM:PARAMETER) or
$(PARAM:PARAMETER:default-value). The
default-value portion of the
variable reference may not contain spaces or parentheses.

1.1.0: December 7, 2009

Miscellaneous Changes

Abuild version 1.1.0 runs at compatibility level 1.1 by
default. You can still turn on backward compatibility with
1.0 by running abuild with the
--compat-level=1.0 flag or by setting that
ABUILD_COMPAT_LEVEL environment variable,
though it is recommended that you do this only while
upgrading trees to avoid accidentally re-introducing
deprecated features. Also, abuild will often be able to
give a clearer error message with backward compatibility
mode turned off.

The embedded version of Groovy has been updated to 1.6.7.

The verify-compiler command now accepts
the --cross option to better support cross
compilers that are in the native platform
type. See Section 29.4, “Adding Toolchains” for a
discussion.

Usability Improvements

When error messages are tied to a file but not to a
specific line in the file, the error message now assumes
the line number “1” rather than not outputting
a line number. This makes tools like emacs, vim, or
eclipse that can automatically take users to the error
location more likely to handle those conditions.

The format of the build duration has been changed to
something that is not mistakenly interpreted as an error
message by vim.

Tighten up the logic for detecting tree roots in partially
upgraded build trees. This reduces the number of false
positives when running an upgrade process over an already
upgraded forest, though it does not entirely eliminate
them. The upgrade caveats section of the documentation has
also been clarified slightly.

1.1.b6: November 10, 2009

Core Functionality Changes

The implementation of global plugins has changed again.
Now, instead of having items declare themselves to be
global plugins, a tree can declare a plugin to be global
for the forest by adding the -global flag
to the plugin declaration in
Abuild.conf. This actually makes
global plugins usable in a real setting.

Bug Fixes

The logic to detect shadowed plugins has been corrected to
eliminate false positives and to provide enough information
to resolve the problem. In many cases, multiple distinct
error messages will be issued when a plugin is actually
shadowed, but this is better than not having the required
information to resolve the problem.

Minor Updates

Parsing of interface files has improved slightly. Some
abuild reserved words are now valid on the right hand
side of assignments without quoting, and handling of
whitespace is more robust, including allowing lines to be
split with continuation characters in some places where
they could not previously be split.

When an abuild 1.0-style
Abuild.backing file is found in an
otherwise upgraded area, a deprecation warning is given
rather than telling the user to run the upgrade process.

1.1.b5: October 28, 2009

Core Functionality Changes

The -optional flag may follow a child
directory in the child-dirs key in
Abuild.conf. In this case, abuild
will not complain if the child directory is missing. This
can be especially useful for
Abuild.conf files that may contain
that are optional trees or optional dependencies.

Windows-related Enhancements

Both the mingw and msvc toolchains now create DLL file
names that include the major version number of the library.
The static library that goes with the DLL remains
versionless so that linking works, but executables that use
the DLL will expect its name to contain the version number.
This is described in Chapter 21, Shared Libraries.

1.1.b4: September 28, 2009

Core Functionality Changes

The global tree dependency feature has been removed as
there was no way to make its use practical. As such,
global plugins no longer have to be in trees declared as
global tree dependencies. Instead, abuild disregards
tree dependency-based access checks when turning on global
plugins. To ensure build consistency when global plugins
are used, abuild disallows use of global tree
dependencies if any tree in the forest uses
external-dirs. Otherwise, a global
plugin may not be in effect if a build were started in the
root of an external tree from which the real forest root
could not be determined.

Changes to Deprecated xml-based Ant Framework

The file preplugin-ant.xml is now
imported for each plugin prior to
loading the local build file or running any targets. This
makes it possible for a plugin to override built-in tasks,
set properties, and do other activities that would not be
possible from inside of hooks. This was introduced
primarily to support static analyzers and similar tools
that require replacing built-in tasks.

1.1.b3: July 28, 2009

Command-line Parsing Improvements

When specifying build set options cases, later options now
supersede earlier ones rather than contradicting them.
This makes it possible to alias abuild
to abuild --no-deps, abuild
--build=desc, or other similar invocations to
suit your preferences while still being able to get
different behavior just by appending additional arguments
on the command line.

As a convenience, abuild now recognizes abuild
--build=set clean as a
synonym for abuild
--clean=set. This
means that if you have abuild aliased to
abuild --build=desc, typing
abuild clean will now have the effect of
running abuild --clean=desc.

Abuild's command-line parsing has been made more
flexible. For options with arguments,
--option=value and --option
value both work, among other possibilities. In
previous versions of abuild, there were inconsistencies
in how options took arguments.

1.1.b2: June 13, 2009

Miscellaneous Changes

Reworked the mutex protection in main build loop slightly
to remove all possibility of concurrent write access to
shared data during a multithreaded build. This appears to
have removed a rarely encountered race condition in which
abuild could crash while building multiple instances of
the same build item on multiple platforms simultaneously in
separate threads.

The --dump-build-graph option has been
changed to output XML data and is now always included in
the output when abuild is running in monitored mode. A
new directory, misc/xslt has been
included in the abuild distribution that includes some
sample XSL-T script that can process some of abuild's XML
output. There are three scripts that generate
dot output of various dependency
graphs. This output is intended to be used as input to the
dot program, which is part of graphviz. Thanks to
Joe Davidson for the dot code and the idea of using
graphviz to visualize the build graph.

Moved reference DTDs from src to
doc so that they're in the same place
in the source and binary distributions.

1.1.b1: May 22, 2009

Version numbering

The version numbering conventions for abuild have changed
slightly such that the first 1.1 release will be called
1.1.0 instead of just 1.1. This makes the phrase
“abuild 1.1” unambiguously refer to all 1.1.x
releases rather than just the first 1.1 release, which will
now be called 1.1.0.

Documentation Updates

There are no significant user-visible changes in
functionality between the latest alpha release and this
first beta release of version 1.1. The principal change is
that the documentation has been largely brought up to date.
The documentation is still very rough and incomplete in
several places, and it has not yet had a full proofreading
pass. However, in most cases, it should now accurately
reflect abuild 1.1 functionality. Additionally, many new
sections have been added. Of particular interest are Appendix B, Major Changes from Version 1.0 to Version 1.1 and Appendix C, Upgrading from 1.0 to Version 1.1.

Other Changes

QTest-based test suites are now invoked using a custom
qtest ant task from both the Groovy
backend and the legacy ant backend. This means that when
qtest-based test suites are run on Windows from the
legacy-based ant backend, it now works to have
qtest-driver be a shell-script wrapper
around the actual perl implementation.

1.1.a9: May 4, 2009

Enhancements to gcc toolchain support

The behavior of ABUILD_FORCE_32BIT has
been expanded, and the variable
ABUILD_FORCE_64BIT has been added. If
exactly one of these variables has the value
“1”, the option
-m32 or -m64, as
appropriate, will be added to all gcc compilation steps.
Additionally, in some cases the CPU portion of the platform
string may be changed. This is a generalization of the
behavior introduced in version 1.0.1, and also a change of
the status of the ABUILD_FORCE_32BIT
variable to “supported” instead of temporary,
at least pending some better solution.

Core Functionality Changes

The attributes key in
Abuild.conf may now have the value
serial for any build item that is
built with GNU Make (i.e., any build
item that has an Abuild.mk file). In
this case, abuild will never instruct make to build that
item in parallel even if --make-jobs is
specified. This is useful for build items that, for
whatever reason, do not build properly in parallel. Many
build items that use autoconf will benefit from setting
this, as will builds that use other tools that create
temporary files whose names may clash with other instances
of themselves.

The behavior of whether expansion by trait and reverse
dependency is repeated has changed again. Now, expansion
by related traits or by reverse dependency is performed
only once by default. In order to have the expansion
process repeated until no more build items are added,
specify the new option --repeat-expansion.

Groovy Framework Changes

The junit test target now accepts attributes that allow the
batchtest task to be run in addition to
or instead of the test task.

Bug Fixes

Fix bug that caused an assertion failure when platform
selectors were used if there were any platform-specific
dependencies on java build items.

1.1.a8: April 22, 2009

Bug fixes

Various refinements have been made to abuild's
multithreaded building code, which should improve both
performance and reliability of multithreaded builds. This
includes correction of a few possible race conditions,
strengthening of multithreaded testing in the test suite,
and correction of a long-standing problem that was visible
only on Solaris but actually turned out to be present on
all platforms.

The java builder code has been corrected so that it invokes
IBM's JDK according to its requirements.

The built-in support for sun RPC's rpcgen has been fixed to
avoid using a GNU-specific option to sed.

Building abuild

Abuild now uses a re-entrant scanner in the lexical
portion of the interface parser, which should further
simplify building abuild. Additional notes have been
added to src/README.build regarding
this and other build-related issues.

1.1.a7: April 20, 2009

Deprecated Features

The interface variable ABUILD_THIS is no
longer deprecated. We can't really deprecate an interface
variable because there's no way to detect or warn for the
use of a specific variable in backend configuration files.
People should use ABUILD_ITEM_NAME
instead of ABUILD_THIS, but the
ABUILD_THIS variable will stick around.

The --ant command line option, which had
been removed in an earlier alpha release, has been
restored, but it only supports arguments of the form
-Dprop=value. Using it will generate a
deprecation warning and will point out the new syntax.
This is to make it easier for users to discover the new way
to pass parameters to builds and to avoid breaking some
scripted builds.

External directories crossing symbolic links is no longer
an error condition. Instead, this will generate a
deprecation warning, and abuild
--upgrade-trees will refuse to upgrade any build
trees that have symbolically linked externals. This change
should make it easier for people to test abuild 1.1
without having to make unwanted changes to their build
areas, particularly when things outside of abuild may be
relying on the symbolic links. As allowing symbolically
linked externals is just postponing the inevitable, people
are still encouraged to avoid them.

Usability Features

Add new flag --find that can be used to
show the location of a build item or build tree. Use
abuild --find
item-name to show the
location and containing tree name of a build item, and
abuild --find
tree:tree-name to show
the location of a tree name.

Abuild is somewhat quieter with --silent
than it used to be.

Bug Fixes

Older versions of abuild would allow assignment of
multiple words to scalar interface variables. This was
never intended functionality, and only happened to work
because of the syntax of make and ant. With the Groovy
backend, this actually causes a problem, so abuild no
properly gives an error when multiple words are assigned to
a scalar interface variable. (Thanks to Brian Reid for
noticing the problem.)

New Help System

Abuild has a new help system. The new help system
provides a more robust ways for help to be provided for
built-in and user-provided toolchains and rules. Pending
full documentation, run abuild --help
help for details. For information on creating
help files, see
src/manual/pending.txt. Help files
have not yet been written for all built-in rules and
toolchains, but this will be done prior to the release of
abuild version 1.1.

The targets rules-help and
interface-help have been removed. For
the ant framework, the targets
properties-help and
hooks-help are still there since the new
help system does not have any support for the ant backend.

Improved Code Generator Support

A new tool, util/codegen-wrapper, has
been provided. This tool can be used to wrap code
generation that uses optional code generators. It is
invoked with a source directory (automatically supplied by
abuild), a cache directory, a list of input files, a list
of output files, and a command used to generate the output
files. It caches the generated output files and checksums
of the input files. If all input files have matching
checksums and all output files are present in the cache,
codegen-wrapper will copy the cached output files into the
output directory. Otherwise, it will run the command and
then cache the output files and update the input file
checksums. Pending documentation of this tool, see
src/qtest/abuild-misc/codegen-wrapper
for an example of its use.

Abuild uses codegen-wrapper in its own
build. As such, the save-autos target
and all support for it have been removed from the build of
abuild itself. The abuild source, as distributed, now
includes automatically generated scanners and parsers, so
flex and bison are no longer needed to build it from the
source distribution.

Backend Changes

Reverted earlier change to the order in which
plugin.mk files are loaded relative to
Abuild.mk. As in abuild 1.0,
abuild 1.1 now loads plugin.mk after
loading Abuild.mk. A new file,
preplugin.mk, is now loaded before
Abuild.mk to allow plugins to provide
initialization that is run prior to parsing of the
Abuild.mk file. The previous change
to loading order was an unnecessary non-backward-compatible
change.

To be consistent with the make backend, the file
plugin.groovy is now loaded after
Abuild.groovy, and the file
preplugin.groovy has been provided for
pre-plugin initialization.

QTest support for both make and Groovy now exports the
TC_SRCS variable automatically.

Built-in flex and bison support have been expanded to use
the codegen-wrapper. The variables
FLEX_CACHE and
BISON_CACHE must be set to enable this.

1.1.a6: April 13, 2009

Ant framework

Reverting an earlier change, abuild will no longer import
ant-hooks.xml or
plugin-ant.xml files. This
enhancement to the ant framework had unintended side
effects that broke some existing builds. As the goal is to
move from the ant framework to the Groovy framework, we
wish to avoid any needless distractions caused by changes
to the ant framework. This means that it is once again no
longer possible to add targets in hook files.

Core Functionality Changes

Both item dependencies and tree dependencies can be made
optional by adding the -optional flag to
them in Abuild.conf. Optional
dependencies are ignored if the items referenced do not
exist. For details, see
src/manual/pending.txt.

New command-line argument --with-rdeps
causes expansion of the build set to include reverse
dependencies of all items in the build set. Running
abuild --with-rdeps in a build item's
directory would cause all items that depend on it, directly
or indirectly, to be built.

Abuild does a better job of detecting the appropriate
libraries for networking, threading, and boost. In
particular, when using a custom installation of boost, it
is necessary only to set BOOST_TOP to
the location of the boost installation. Abuild's build
will automatically figure out includes, library paths,
preprocessor settings, and library naming conventions. For
details, see src/README.build.

1.1.a5: April 7, 2009

Non-compatible changes

Absolute path externals are no longer supported.

The --winpath option to externals has been
removed. Without absolute path externals, it is no longer
needed.

Note: in a later release, this was changed to a
warning. Externals may no longer be symbolic
links nor may they cross symbolic links. If you were
relying on symbolically linked externals before, you can
instead create dummy directories with
Abuild.backing files or with their own
externals pointing to the real location.

Read-only externals are no longer supported. Use of the
-ro flag generates a deprecation warning
and is ignored. Instead, if you need to make parts of your
build tree read-only, use --ro-path or
--rw-path (described below). This gives
you much greater and more precise control over what is
read-only than read-only externals did.

Child directories (specified with
child-dirs) may no longer be nor may
they cross symbolic links. Most likely, this would not
have worked in previous versions either, but abuild now
specifically checks for this case.

When parent-dir appears, it must point
up, and child-dirs values must point
down in the file system. “Interleaved” build
items are no longer permitted. There must be no
Abuild.conf files in any directories
between a parent directory and its child build items. In
practice, the chances of ever finding a build tree that
doesn't already obey these restrictions are very low, and
any configuration that fails to follow these guidelines
would have been very confusing, so this change is not
likely to be noticed.

Deprecated Features

Use of read-only externals generates a deprecation warning,
but in fact, it's more than deprecated—it's entirely
ignored. The deprecation warning indicates that use of
-ro could potentially become an error in a
post-1.1 abuild release.

Use of external-dirs to point to a
build tree that has been upgraded to use 1.1 syntax will
generate a deprecation warning.

Use of this,
deleted, or
parent-dir in
Abuild.conf, or having a tree root
that does not include the tree-name
key will generate a single warning suggesting that you
should upgrade your build trees using abuild
--upgrade-trees. The specific locations of the
deprecated features is not reported. This is to discourage
attempts to manually upgrade trees. The upgrade process is
complex, and all the complexities are managed automatically
by abuild --upgrade-trees. In general,
abuild tries to avoid suggesting that you run an upgrade
if it concludes that the upgrade will not be able to do
anything. Detailed documentation of the upgrade process
will be included in the manual prior to the final 1.1
release. In the interim, see
src/manual/pending.txt in the source
distribution.

Use of Abuild.backing files below the
root of the build forest (defined) below is deprecated. A
new syntax for Abuild.backing files
has been introduced and is also described below. Use of
the old format is deprecated.

Note: ABUILD_THIS was removed
from the deprecated list in a later release. The
interface variable ABUILD_THIS is
deprecated and has been replaced by
ABUILD_ITEM_NAME. Note that abuild is
not able to detect use of $(ABUILD_THIS)
in Makefile fragments. It will, however, warn about them
when they are used in Abuild.interface
files.

Pending Documentation

Documentation for significant new features that have not
yet been incorporated into the manual now appear in the
file src/manual/pending.txt.

Groovy Framework Changes

Compiled rules files are now cached, resulting in a
significant performance improvement.

When the groovy rules are used, Groovy
sources are now expected to be in
src/groovy instead of
src/java.

The package-rar target has been replaced
with package-high-level-archive.
Various parameter and attribute names have been updated for
consistency. The java rules should
now be considered in a soft freeze for version 1.1.
Non-compatible changes can still be made for cosmetic
reasons or to fix minor problems, but the rules should be
in pretty close to final form. Generation of javadoc and
junit testing may still change more significantly.

Compatibility Mode

Compatibility level can be set using the
ABUILD_COMPAT_LEVEL environment variable in
addition to use the --compat-level command
line argument.

New Build Tree Structure

This version of abuild includes a new build tree
structure. The highlights of this structure are named
build trees, name-based tree dependencies instead of
externals, multiple backing areas, improved build ordering,
and removal for the need of
parent-dir.

With the exception of the non-compatible changes listed
above, abuild will continue to recognize the old build
tree structure and will internally map it to the new
structure by assigning randomly generated names to build
trees. If abuild finds deprecated 1.0 features while
traversing the build tree, it will notify the user that the
trees can be upgraded with the abuild
--upgrade-trees command. Needless to say, if you
are trying to use the same build tree under both versions
1.0 and 1.1 (during a transition period), you should hold
off on performing your upgrades. Upgraded trees will not
be recognized by abuild 1.0.

The way backing areas work has been significantly improved.
As in the case of the new build tree structure, abuild
will continue to recognize 1.0-style
Abuild.backing files when running in
1.0 compatibility mode (the default).

New interface variables ABUILD_ITEM_NAME
and ABUILD_TREE_NAME have been
introduced. These variables contain the value of the
current build item name and its containing tree. The
ABUILD_ITEM_NAME variable replaces the
deprecated ABUILD_THIS variable.

Command Invocation Changes

Build set all builds all items in all
known trees as before, but with the new build structure,
this may include trees that were not previously included.
In particular, abuild now knows about all trees in the
forest, not just those that are tree dependencies of the
current build item.

The new build set deptrees builds all
items in the current tree and all its tree dependencies.
It has the same semantics as all had in
abuild 1.0, and does the same thing as
all in 1.0-compatibility mode.

New arguments --ro-path and
--rw-path have been added. These replace
read-only externals as the way to make parts of the local
build forest read-only. See discussion in
src/manual/pending.txt for details.

New option --no-deps is described below.

Build Behavior Changes

When abuild is run with no build set arguments,
--with-deps is enabled by default. In
order to build a build item without
its dependencies (effectively assuming that the
dependencies are up to date), run abuild with the
--no-deps option.

Removed all clean targets previously
provided by backends. In older versions of abuild, the
clean target was passed to the backend
under the special case of abuild being invoked from
inside the output directory. Now abuild implements the
clean target internally for that case.
Abuild always has and continues to implement
clean internally for invocations that
are not in an output directory.

Abuild always has and continues to guarantee that it will
build all dependencies of an item before it builds the
item. Previous versions of abuild would rearrange an
initial build that built all items alphabetically,
deviating from that order only to satisfy dependencies.
Abuild now uses, as an initial ordering, build items
sorted alphabetically within trees, with trees sorted in
dependency order. In other words, if tree
A declares a tree dependency on tree
B, then abuild will build all items
in A before building any build items
in B. As always, build ordering is
considered an implementation detail that should not be
relied upon.

Platform Changes

Platform-specific dependencies now obey user-supplied
platform selectors. The rationale for not doing this
before was that the command-line and environment should not
affect the shape of the build graph, but that's not really
a good reason since this is a myth anyway. People can
always run with DFLAGS=-g or set an
environment variable used by a specific platform plugin's
list_platforms script to suppress the
platform. If a specific compiler or option is required, it
can be specified explicitly with the platform-specifier in
the dependency.

To explicitly disregard user-supplied platform selectors,
it is possible to specify "default" as the platform
selector, as in

deps: item -platform=platform-type:default

It is also possible to specify an explicitly empty option,
as in

deps: item -platform=platform-type:option=

Both the empty option and default platform
selector are available on the command-line as well, making
it possible to run

abuild -p option=debug -p native:default

or

abuild -p option=debug -p native:option=

Abuild now passes information about the native platform
to all list_platforms programs, which
are supplied by plugins that are offering support for new
compilers. list_platforms is now
invoked as follows:

list_platforms [ --windows ] --native-data oscputoolset

Core Functionality Changes

Abuild now supports global plugins. This is implemented
through introduction of a new, general-purpose key in
Abuild.conf:
attributes. (Note:
implementation of this feature was changed in a subsequent
release.) This key can be used to flag certain
build items as having specific properties that abuild
recognizes. At present, only two attributes are
recognized:

Note: this feature was removed in a subsequent
release.global-tree-dep: This attribute may
be assigned to any root build item of an explicitly
named tree. Such a tree may not have any tree
dependencies of its own and is implicitly treated as if
it were declared as a tree dependency by all other
trees.

Note: this feature was changed in a subsequent
release.global-plugin: This attribute may
be assigned to any build item that otherwise meets the
qualifications for being a plugin. It must reside in a
tree with the global-tree-dep
attribute. Note:
global-tree-dep was removed in a
later release. This item will then be treated
as if it had been explicitly listed as a plugin for all
build trees. This is a very powerful feature which must
used with care. Good uses for it might include
implementing project-wide checks, such as making sure
appropriate environment variables are set or appropriate
dependency rules are followed, or for adding new
platforms or platform types that may be used by all
build items in a forest. Care should be taken to avoid
introducing global plugins that wider consequences than
you might initially expect. Global plugins should
generally be coded in such a way that their impact can
be disabled in some way.

Implemented abuild --upgrade-trees. You
should use this command to upgrade your build trees rather
than attempting to upgrade your trees manually. Although
abuild will work fine with mixed 1.0/1.1 trees, you will
get a lot more warnings and possibly incorrect results in
some cases (though no such cases are known) if you
partially upgrade your trees. There is a
lot to keep track of when upgrading your trees.
You are much better off letting abuild do it for you.
Documentation on the upgrade process, for the time being,
can be found in
src/manual/pending.txt.

1.1.a4: March 19, 2009

Deprecated Features

No features have been deprecated in this release.

Documentation Changes

Documentation for the Groovy framework has been moved to
src/manual/groovy-framework.txt
pending full inclusion in the manual.

Java examples that are not specifically illustrating the
ant framework have been converted to use the Groovy
framework. The rest have been moved into an ant-specific
portion of the test suite. The text remains in the manual,
but the files are no longer included. Prior to the release
of version 1.1, new examples to illustrate the Groovy
framework will be introduced, ant the ant framework will be
mentioned briefly in an appendix.

Core Functionality Changes

Support
--compat-level=x.y.
When specified, backward compatibility support is disabled
for features that were deprecated at or before version
x.y.

Abuild now prints the total clock time that elapsed
during a build right before it exits. The time is printed
in the form HH:MM:SS.

In preparation for deprecation of
parent-dir, the value of
parent-dir is required to point up in
the file system, and all values of
child-dirs are required to point
down. Additionally, if either
parent-dir or
child-dirs reach more than one
directory away, no Abuild.conf files
are permitted in intervening directories.

These changes, along with the existing check that an item's
child's parent point back to the item, are sufficient to
enable abuild to safely ignore the value of the
parent-dir key.

As an intermediate step toward adoption of the new
traversal system, we now walk up the tree looking for an
item that doesn't have us as its child when finding the top
of the forest. The old behavior was to follow
parent-dir, which is now ignored.

1.1.a3: March 16, 2009

Deprecated Features

No features have been deprecated in this release.

Changes to Groovy Framework

Some default path names have changed. See
rules/java/_base.groovy for details.
This will likely continue to change until the main
java rules have been nailed down.

Targets have been added for copying and signing JARs, and
for creating RARs, WARs, and EARs. The RAR target happens
after copying and signing of jars. There's nothing
RAR-specific about it. It could be generalized to create
any kind of JAR that could contain other JARs.

Support for JUnit-based tests have been added to the
built-in java rules.

Calls to abuild.appendParameter will pre-initialize the
parameter with the result of calling
resolve on it. This means that
attempting to append to an interface variable will
effectively copy the interface variable to a parameter and
then append it.

Variable-like constructs on the right-hand side of an
assignment or left shift inside of
parameters call are no longer
automatically resolved as parameters. You now must use
resolve explicitly. This is to reduce
confusion that could step from the fact that you always had
to do this for some cases, and that using a parameter in a
context where it is not magically resolved would result in
having a ParameterHelper object,
which is not useful in itself. This is a case of removing
a little bit of convenience in a common case to avoid
creating a very obscure error in a less common case.
Although having to explicitly resolve variables on the
right hand side of assignments is not “normal”
in a programming language environment, it is similar to
variable assignment in a properties file, shell script,
make file, or even abuild interface file, which makes it
consistent with the rest of abuild.

Core Functionality Changes

It is now possible to declare local variables in an
interface file. Local variables are visible to the backend
of the build item to which they belong, and their scope
extends from the main Abuild.interface
file to any after-build files, but nothing about them,
including their declarations, is exported to depending
build items. This means that local variables with the same
names may be used in multiple build items' interface
files. Declare local variables using the syntax

declare variable local type[ = initialization]

1.1.a2: March 11, 2009

Deprecated Features

The following features, each of which is discussed
elsewhere in these relates notes, have been deprecated in
this version:

LINK_SHLIBS. No functionality
changes have been introduced relative to version 1.0.3,
but using LINK_SHLIBS now results in
a deprecation warning.

The following feature was listed as deprecated in 1.1.a1
but is no longer deprecated:

The abuild.hook-build-items is no
longer deprecated since the -with-rules
flag for dependencies as been removed in favor of a
different solution that can't be applied to the
ant backend.

Changes to Groovy Framework

The java rules have been completely
rewritten.

The src/TODO file remains the primary
location of documentation of the Groovy framework while it
is still in flux, so these notes contain only a very brief
summary of changes.

An improved syntax has been provided for setting
parameters. This takes advantage of Groovy's
meta-programming capabilities to allow a closure passed to
the parameters method to contain
parameter settings that look like normal variable
assignments.

Parameter names have been changed to use camelCaps instead
of dashed-components to make the syntax more natural when
setting parameters from a closure.

All getVariable methods have been
replaced with calls to methods whose name start with
resolve.

There is now a replaceClosures method
that allows closures for a target to be replaced rather
than appended to. This practice should generally be
avoided, and seldom be necessary based on the way the
default rule implementations work. (You can already
provide your own closures to run instead of the default
ones.)

Changes to ant framework

Note: this change was removed in a subsequent
release. This change was actually introduced in
version 1.1.a1. Abuild now complains if the
ant-hooks.xml file for a hook build
item does not exist.

Changes to make Framework

Note: this change was reverted in a subsequent
release. The order in which files are loaded by
the GNU Make backend has been
changed slightly. plugin.mk files and
the base rules (which load the compiler toolchain support
files) are now loaded before
Abuild.mk. This makes it possible for
Abuild.mk files to modify variables
set in those places and also provides a mechanism for
plugins and built-in rules to supply default values for
parameters that can be referenced from
Abuild.mk.

Core Functionality Changes

The -with-rules option to the
deps key in
Abuild.conf, introduced in 1.1.a1, has
been removed. It didn't turn out to be a very good idea.
Instead, a new, unified method for build items to provide
rules has been added. All build items, not just plugins,
provide rules by creating a rules
directory and putting a named rules file in a subdirectory
named after the target type. In addition, a subdirectory
named all may be used to provide rules
that are valid for all target types.

As a result of this change, all uses of
BUILD_ITEM_RULES and of
Rules.mk are now deprecated.
Additionally, since there is no facility to provide loading
of named rules in the ant
framework, use of abuild.hook-build-items
is no longer deprecated (except in as much as the entire
ant framework is deprecated).

When build items want to use rules provided by another build
item, they just place the name of the rules (without the
.mk or .groovy
suffix in RULES or
abuild.rules just as they would for
plugin or built-in rules.

As part of this change, the make/rules
and groovy/rules directories have been
merged and placed in rules at the top
of the abuild distribution. Additionally, the
empty rule sets for both Groovy and
make have been moved into the rules/all
directory.

The interface system now supports
non-recursive variables. A variable
can be declared non-recursive by putting the keyword
non-recursive in the declaration after the
variable name and before the type.

When an interface variable is declared as non-recursive,
only assignments from the item itself and its directly
declared dependencies are effective. Specifically, when
importing an interface, only assignments from the item that
owns the interface imported. Since abuild imports
interfaces of its direct dependencies, this causes the
behavior of seeing only assignments in direct dependencies
and in the item. To avoid seeing assignments from the item
itself, place those assignments in an after-build file.

Non-recursive variables can be useful for carrying
information for subsystems that handle recursive
dependencies on their own. Examples could include manifest
classpaths or shared library information.

It is now possible to initialize an interface variable at
the time of declaration using the shorthand syntax

declare variabletype = initialization

1.1.a1: February 20, 2009

Deprecated Features

Some features have been deprecated. Deprecated features
always result in a warning. You can pass the
--deprecation-is-error to abuild to
cause it to treat use deprecated features as an error
instead.

The following features, each of which is discussed
elsewhere in these relates notes, have been deprecated in
this version:

BUILD_ITEM_RULES

abuild.hook-build-items
(Note: removed from deprecated list in a
subsequent release)

abuild.use-local-hooks

Major Enhancements

A new Groovy-based backend has
been added. Although, like all backends, it could be used
to build build items of any target type, it is primarily
intended as a replacement for the Apache
Ant backend. This first alpha release of 1.1
includes a rudimentary collection of rules for building
Java and Groovy code currently called
java_proto. These rules may change in
non-compatible ways throughout the 1.1 alpha testing
period. The Groovy backend is
invoked through Java APIs. A single instance of the Java
Virtual Machine is shared for all Groovy-based builds.

For now, documentation on the interface to the Groovy
framework can be found in src/TODO in
the abuild distribution. It will be moved into the manual
as it is stabilized.

The same JVM that is used to run Groovy-based builds is now
also used to invoke ant-based builds. As such, abuild
runs all ant builds from a single JVM and no longer invokes
ant from the command line. This can result in a noticeable
performance improvement.

Licensing Changes

Abuild itself remains under the terms of Version 2
of the Artistic license. Abuild now also embeds the
embeddable JAR from the Groovy distribution. Groovy is
distributed under the terms of the Apache License. A
NOTICE.txt file has been included in
abuild's source distribution in accordance with that
license.

Changes to command-line syntax

The --deprecation-is-error option has been
added. When specified, deprecation is considered an error
rather than a warning.

Note: a limited version of --ant
was added back in a subsequent release. The
--ant and
--no-abuild-logger options are no longer
supported since abuild now invokes ant through Java APIs.

Abuild now recognizes arguments of the form
variable=value
as variable definitions. Any such variable definitions are
automatically passed to all backends. This, rather than
using --make or --ant is
now the recommended way of overriding variables. Any
variables defined in this way are made available to the
ant backend and to the ant
project in the Groovy backend as
properties, and to the GNU Make backend as variables passed
on the command line. They are also passed to the
Groovy backend in a manner that
causes them to override variable values that are set in
other ways, as long as the documented interfaces are used
for getting and setting variables.

The --just-print,
--dry-run, and --recon
options are no longer synonyms for -n.
These are accepted as synonyms by GNU Make, which is why
they were originally supported by abuild as well.

Core Functionality Changes

Note: this change was reverted in a subsequent
release, and a different solution was implemented in its
place. When declaring dependencies, a new flag
-with-rules may be specified. This causes
the build item to load Rules.mk
(make), ant-hooks.xml (ant), or
Rules.groovy (Groovy). This replaces
the now deprecated BUILD_ITEM_RULES make
variable and abuild.hook-build-items ant
property. This change means that there is now a unified
mechanism for forcing build item-supplied rules to be run
rather than having a separate mechanism for each backend.
In some rare cases, it may be that a build file
only has item-based rules. In this
case, you will have to create an empty build file (or one
containing only comments) so that abuild will still know
which backend to use for building the item.

Since you can't declare a dependency on yourself, if you
wish to use your own rules, you can specify
Rules.mk in
LOCAL_RULES (make) or
ant-hooks.xml in
abuild.local-buildfile (ant).

When traversing a build tree with a backing area, abuild
now accepts non-existent child directories without
requiring a corresponding directory to exist in the
backing area. This check served no useful purpose, and it
was removed in preparation for the upcoming revamping of
how backing areas work.

The -n is now supported for all the
backends, not just make. For the ant and Groovy backends,
abuild doesn't actually invoke the backend but instead
just prints some information on what targets would be run.

Considerable additional information is output when abuild
is run with --verbose. In particular,
there is much more information about how abuild starts up
and invokes backends. This should make it easier to solve
certain types of configuration problems, such as abuild
picking the wrong version of make.

Although abuild still does not require
JAVA_HOME or ANT_HOME to be
set, it will start up slightly faster if they are set. The
reason for this is that abuild actually invokes
java and ant to more
reliably infer values for JAVA_HOME and
ANT_HOME if they are not already set.

Build item names are no longer permitted to start with the
“-” character.

Changes to ant framework

Note: this change was reverted in a subsequent
release. All files from which hooks may be
loaded, including hook build items'
ant-hooks.xml files, plugins'
plugin-ant.xml files, and any file
specified as abuild.local-buildfile are
now imported. Before, plugin and
build item-supplied files were used only for loading hooks.
This means that it is possible to add new targets in
plugins and hook build items. Some caveats are described
in the documentation for this feature. Most notably, when
multiple instances of a new target are imported, only one
will actually be used. The recommended practice is for
newly defined targets to do nothing other than call
run-hooks to run a hook of the same
name.

The property abuild.use-local-hooks is
no longer used. Instead, the ant backend always behaves as
if it were set, meaning that it always uses the local build
file for hooks. People were in the habit of setting the
now deprecated abuild.hook-build-items
to contain the current build item and writing hooks that
apply only to the local build item. This functionality is
intended to be offered by local build files, and that
mechanism should be used instead. If you have a build item
that offers hooks for others and also wants to use them for
itself, it can set
abuild.local-buildfile to
ant-hooks.xml or import
ant-hooks.xml from its existing local
build file.

Note: this change was reverted in a subsequent
release. Abuild now loads the
groovy ant task. Parts of the abuild
ant framework use this task to embed Groovy code. It is
recommended that you switch to the
groovy backend rather than using
this task, but embedding Groovy code in your ant files may
help with a transition to the new backend.

Since abuild no longer invokes ant from the command line,
the --ant option has been removed.
Note: a limited version of --ant
was added back in a subsequent release. As such,
it is no longer possible to pass arbitrary flags to ant.
The most common use of this was to pass
-Dprop-value options to ant. This can now
be accomplished through abuild's new
VAR=value argument syntax as described
above. Certain things that used to be possible before,
such as running abuild --ant -p, are no
longer supported. A future 1.1 alpha version of abuild
will introduce a new help system, so this feature should
hopefully not be missed.

Since abuild now uses its own ant launcher to start
ant-based builds using the ant Java API, the old problem of
ant.bat not properly reporting failures on Windows is no
longer relevant. This means that ant-based failures are
now properly detected on Windows.

The --no-abuild-logger is no longer
supported. Abuild now always uses the abuild logger when
running ant.

Building Abuild

Abuild has already required Java 1.5 since its own Java
code uses generics. This requirement is made more firm now
since abuild's own Java code now also makes use of some
thread pool functionality that was added in version 1.5.

Abuild now requires boost version 1.35 or greater since
it uses the asio (Asynchronous I/O) library to communicate
with its Java build launcher.

When bootstrapping abuild, you must now run the
BootstrapJava.groovy script in abuild's
src directory to build the Java code.
A full Groovy installation (>= 1.5.7) is needed to build
abuild from scratch. A Groovy installation is not
required run abuild as abuild embeds Groovy.

Usability Improvements

Starting in 1.0.3, if any build failures occur in a given
abuild run, abuild issues an error message indicating
this at the end of its output. Now this error message is
followed by a list of which build items failed on which
platforms.

1.0.3: January 9, 2009

NON-COMPATIBLE CHANGE:
removal of LINK_SHLIBS

Although care is taken to avoid introducing non-compatible
changes within a minor release, it was necessary to change
how shared libraries are linked as the old behavior caused
too many problems. Specifically, prior to abuild 1.0.3,
shared libraries were not linked unless the
LINK_SHLIBS variable was set. Starting
with version 1.0.3, this variable has been removed, and
builds are conducted as if the variable were set: shared
libraries are always linked. This is almost always the
correct behavior for systems that support linking of shared
libraries. Without this, it is very easy to end up in a
situation where replacing one version of a shared library
with another one results in undefined or multiply-defined
symbols at runtime. One possible consequence of this
change is that, in some cases involving mixing of shared
and static libraries, a single shared library may be linked
into multiple shared libraries. This is usually (but not
always) harmless, but it is also usually wasteful. If you
encounter this situation, the best option would be to
rework your build to avoid whatever arrangement is causing
this. Alternatively, you can manipulate the value of the
LIBS variable in your shared library
build item's Abuild.mk file. The old
behavior was based on an incomplete analysis of usage of
shared libraries. It optimized for the unusual case of
mixing shared libraries with static libraries rather than
the more normal case of being able to replace earlier
versions of shared libraries with later versions that may
have different dependencies.

Enhancements

A new command line option,
--clean-platforms, can be used to
restrict which platforms' directories are removed by any
abuild clean operation.

A new key, build-also, is now
supported in Abuild.conf. This key's
value is a space-separated list of build items that should
be automatically built if the original build item is added
to a build set. No dependency relationship is implied.
This provides a more robust method than dependencies of
creating virtual “top-level” build items. A
corresponding element has been added to the dump data
output as well.

When --clean is used to clean a build set,
abuild now attempts to clean all
build items, not just items with build files. This means
abuild will attempt to clean interface-only items,
plugins, and other items that it previously would not have
attempted to clean.

A new option, --dump-interfaces, has been
added. Using this option during a build causes abuild to
write an XML dump file of the full state of the interface
system for every writable build item. For details, see
Section 17.6, “Debugging Interface Issues”.

Build sets down and
descending have been added as aliases for
desc.

Behavior of the special platform selector skip
has improved. Rather than unconditionally disabling builds
of the given platform type, it just prevents them from
being selected by default. Builds for a platform type for
which skip has been specified may now be done
in order to satisfy a platform-specific dependency.

The skip platform selector may now be used for
platform types indep and java.
When java:skip or indep:skip is
specified as a platform selector, no builds for the given
platform type will be performed unless needed to satisfy a
dependency.

When expanding the build set with
--related-by-traits, abuild now repeats
the expansion until no more items are added.

Bug Fixes

A failing qtest test suite when invoked from ant now
properly causes the build of that item with the
check or test targets
to fail.

If a build item has instances of another build item in its
dependency chain for more than one platform, abuild
previously ignored all but the first instance of the second
item's interface. (Recall that abuild creates a separate
instance of each item's interface for every platform on
which that item builds.) Abuild now properly treats each
instance of the interface separately for purposes of
importing interfaces into a dependent item's build. This
bug could only be exercised by creating multiple build
items that depend on a common build item using different
platform-specific dependencies.

Usability Improvements

If any build failures occur in a given abuild run,
abuild now issues an error message indicating this at the
end of its output just before exiting. This makes it
easier to recognize a failed build by looking at the end of
abuild's output. This is especially helpful when for
parallel builds or builds with -k since,
in those cases, the output of the failed builds may not be
at the end of the output.

Abuild is clearer about reporting when a build item
fails. Additionally, if a build failure of one item causes
other items to be skipped, this is now reported as well.

Internal Changes

A minor change was made to make it easier for users to
create plugins that would enable use of GNU Make to build
Java code. This could make it easier to create prototypes
of different back-end build approaches for Java without
having to modify abuild's internals.

1.0.2: October 7, 2008

Abuild no longer includes the minor release of Red Hat
Enterprise Linux and Centos releases in the platform string.
The minor release number is not necessary as the minor
releases are intended to be binary compatible. This allows a
Red Hat Enterprise Linux 5.2 system to use a backing area
built by a Red Hat Enterprise Linux 5.1 system, for example.

Minor fixes were made to C++ source files in the test suite
and examples so that they would compile properly with gcc
4.3.

In some cases, shared libraries would be linked with the C++
compiler even when LINK_AS_C was set.
This has been corrected.

Setting OFLAGS, DFLAGS,
and WFLAGS in
Abuild.mk files had no effect because of
the way these variables were assigned in toolchain support
files. Abuild's built-in toolchains have been fixed to
initialize these with ?= instead of
=. This should make it possible to
override these variables globally at least for abuild's
built-in toolchains. Overriding these variables globally is
generally not a good idea in any case, however. Thanks to
Ben Muzal for reporting the problem.

1.0.1: May 28, 2008

Minor updates to test suite to make it more portable. In
particular, abuild's test suite is now known to pass on
Solaris 8.

Abuild was previously passing a JAR file rather than a
directory to ant's
-lib argument. This has been corrected.
(Thanks for the problem report from Craig Pell.)

If AUTOCONFIGH is not set, abuild's
autoconf rules will not run autoheader.
This makes it possible to create an autoconf build item
without generating a header file if desired.

When autoconf invokes the compiler, it now honors any flags
or includes set by dependencies. (Thanks for the problem
report from Joe Davidson.)

Include two small patches to make abuild build properly in
MacOS Darwin. (Thanks for the patches from Joe Davidson.)

With --verbose, abuild now prints the
backend command that is invoking. (Thanks for the suggestion
from Craig Pell.)

Documentation updated to add autoconf, automake, and GNU
diffutils, and gcc configured with gnu ld to the list of
system requirements.

Abuild now mentions when nothing is built but some native
build items were skipped due to lack of available platforms.
Hopefully this will reduce confusion when Windows users
without any valid compilers or cygwin perl type abuild and
don't get any output. Also, when
--verbose is specified, abuild always
mentions when it skips any build item because of lack of
build platforms.

Bug fix: if tree A contained a plugin
but did not use it, tree B had
A as an external and used the plugin,
and tree C had A
and B in that order as externals and did
not use the plugin, C would have not
realize that the plugin was a plugin in any tree. This would
cause a segmentation fault when loading the interface. This
problem has been corrected because abuild now has a more
robust way of keeping track of whether a given build item is
ever a plugin.

Enhancement: When the abuild.main-class
property is set in Abuild.properties,
abuild now sets the Main-Class
attribute in the JAR file's manifest. This doesn't solve the
problem of adding custom attributes to manifest files in the
general case, but it does address the most common situation.
Thanks to Craig Pell for providing an implementation.

When building with Visual C++, embed the manifest file, if
any, into the executable or dll file. Thanks to Matt Nassr
for the suggestion and pointer to the relevant information.

Temporary change: for abuild version
1.0.1, the environment variable
ABUILD_FORCE_32BIT may be set to the value
1 to force abuild to generate 32-bit
code on 64-bit platforms under certain conditions.
Specifically, on a ppc64 platform, abuild will
pass -m32 to gcc and will
use ppc as the CPU type in the platform string.
Likewise, on an x86_64 platform, abuild will
pass -m32 to gcc and will
use ix86 as the CPU type in the platform string.
Note that abuild will not otherwise override the type of
object file generated by your compiler based on the platform
string. This means if you are building on a 64-bit system
with a compiler that generates 32-bit object files, abuild
will happily create 32-bit object files in a directory whose
name suggests 64-bit code. (This is the case on Red Hat's
ppc64 distribution at least with Red Hat
Enterprise Linux 4 and 5.) This change is temporary and may
be removed in a future release in favor of a more robust
solution for generating both 32-bit code and 64-bit code on
64-bit systems.

1.0: February 12, 2008

WARNING ABOUT Java SUPPORT:
Java support is considered alpha at the time of
release of abuild version 1.0. This means the Java support
in abuild version 1.1 may not be compatible with the Java
support in abuild version 1.0. We are in the
process of rethinking how abuild should support Java, and
it is possible that a wholesale redesign of abuild's Java
support will be forthcoming.

Changes from earlier versions

Added --no-dep-failures option. When used
with -k, tells abuild to attempt to
build items even when their dependencies have failed.

Bug fix: a failing JUnit test suite run now causes the
build item to fail.

Added test-only target to test a build
item without depending on all.

Documentation update: clarify that
XLINKFLAGS should not be used for
libraries. The documentation still reflected an earlier
idea of what this variable should be used for.

1.0.rc1: December 3, 2007

Hitting CTRL-C in Windows while abuild was running
ant would sometimes leave the
console window in an unusable state as
ant, a batch file, tried to ask
the user whether to terminate the batch job. On Windows,
abuild now waits for subsidiary processes to exit before
exiting itself.

Trailing whitespace is now trimmed around
abuild.hook-build-items in
Abuild-ant.properties.

New command line option --find-conf
directs abuild to find the first
Abuild.conf at or above the current
directory and to run the build from there.

Enhance handling of absolute externals so that an absolute
external directory may be a symbolic link.

Many additional improvements have been made to the
documentation, thanks to input from reviewers mentioned in
Acknowledgments.

The HTML version of this complete document in the binary
distributions is now in
doc/html/abuild-manual.html instead of
doc/abuild-manual.html. A multi-file
version of the HTML documentation is now also generated. Its
entry point is doc/html/index.html.

1.0.b3: November 13, 2007

Support has been added for read only externals and for
specifying a separate path for an external that is used only
on Windows.

If a
WHOLE_lib_libname
variable is set during a build using the
msvc compiler, an error message will be
generated. Previously, the whole library instruction would
be silently ignored.

Numerous improvements have been made to the documentation,
thanks to input from reviewers mentioned in Acknowledgments.

VxWorks and XLC support have been removed from abuild and
are now available as plugins in a build tree maintained
separately from abuild.

Javadoc support is no longer provided by the default ant
rules but is instead provided by a doc
hook, which is provided separately.

New Features

External trees may now be specified as absolute paths.
This makes it easier to support external trees that contain
things like libraries of build items that may be maintained
separately from the projects that use them.

The -C
directory option to the
abuild command tells abuild to change directories to
the given directory before doing anything. Similar to
make's -C
option.

The -lowpri option to
platform and
native-compiler commands output from
list_platforms scripts may now be
specified when adding new platforms and native compilers
from plugins.

C/C++ rules will, in most cases, recognize orphan targets
are deal with them properly. (Stray object files in
subdirectories of the output directory will not currently
be detected.)

The new make variable LINKWRAPPER can be
set on the command line or in the
Abuild.mk file to specify the name of
a command to wrap the link step. This is intended to be
used to support tools such as
Purify which wrap the link
command in this fashion.

The new variable LINK_AS_C may be set in
an Abuild.mk file to cause all shared
libraries and executables in that build item to be linked
as straight C code instead of C++ code. This avoids a
dependency on the C++ runtime libraries for straight C
code.

The -ansi flag is no longer passed to
g++ by default for the
gcc and mingw
compilers. If you want it, create a plugin that adds it to
XCXXFLAGS (or
XCFLAGS) in
plugin.mk conditionally upon the
compiler. In older versions, -ansi was
passed to g++ but not
gcc.

The doc target for Java builds no longer
runs javadoc. Instead, this capability
must be provided by a plugin. The reason for this change
is that there is too much site-specific policy in how the
javadoc task would be invoked. In light
of this, the pre-doc and
post-doc hooks have been replaced by a
doc hook.

A few error messages have been cleaned up so that, whenever
possible, all abuild error messages are of a form that is
parseable by the error-handling code in Emacs and Eclipse.
(Most error messages already conformed, but a small number
did not.)

Bug Fixes

The autoconf rules have been fixed so
that they do not generate warnings about undefined
variables and work better by default for cross compiles.

File-specific OFLAGS,
DFLAGS, and WFLAGS
variables now work properly when set to the empty string.

On Windows, abuild no longer attempts to run perl if
Cygwin perl is not the first perl in the path. In verbose
mode, a message to this effect is printed when perl is not
found.

1.0.b1: September 28, 2007

Warnings About Next Release

Note: This is intended to
be the last release to include VxWorks and xlc support
inside of abuild. Abuild's VxWorks and xlc support
code should be moved into plugins prior to the next beta
release of abuild.

Documentation Changes

The documentation has been substantially reorganized. Many
new sections have been added, and many parts have been
rewritten.

Examples are now spread throughout the documentation rather
than being grouped together in one section. (See Appendix L, List of Examples for a convenient list of
examples.) The contents of files referenced from the
examples are now included inline in the text. The contents
of every file in the doc/example
directory are no longer included in the document.

The documentation has been converted from Texinfo to
docbook.

The documentation in the binary distribution is now
installed as doc/abuild-manual.pdf and
doc/abuild-manual.html. There is also
now a cascading stylesheet called
doc/stylesheet.css that has to be in
the same directory as the HTML version of the
documentation.

VxWorks Changes

Shared library and partial load script support has been
added to vxworks. When building an executable, abuild
generates
binname.loaddata
which is an executable shell script that copies all files
that need to be loaded to a given directory in sequential
order.

Basic Functionality Changes

Subtle changes have been made to how abuild picks which
targets to apply to which build items: explicit targets are
no longer applied to build items being built just to
satisfy dependencies unless the new
--apply-targets-to-deps option is
specified.

--with-deps is now exactly the same as
--build=current. Both behave the way
--with-deps behaved in previous releases.
To get the old behavior of
--build=current, also specify the
--apply-targets-to-deps option.

When cleaning with a clean set, dependencies of items in
the clean set are no longer cleaned by default. To cause
them to be cleaned as well, use the
--apply-targets-to-deps option along with
--clean.

The --verbose option now prints additional
information about what abuild is doing in addition to
passing verbose flags to make
and ant.

The --silent flag now passes
-quiet to ant
in addition to suppressing some make output and some of
abuild's own output.

Build item scoping rules have changed slightly: a build
item no longer has automatic access to items in grandchild
scopes or lower (A can still see
A.B, but it can no longer see
A.B.C). Access can still be granted
using the visible-to key if needed.

Bug fix: if --dump-data and
--monitored were both specified, the dump
data output is now properly delimited by monitor
statements.

Ant/Java changes

The ANT_HOME and JAVA_HOME
environment variables are no longer required. If
ANT_HOME is set, abuild will still run the
copy of ant in
${ANT_HOME}/bin, but if it is not set,
abuild will now attempt to run ant
from the path. This makes abuild completely free of
mandatory environment variable settings.

The ability to generate wrapper scripts to run Java
“executables” has been moved into the standard
ant support for abuild. The
old Java wrapper example has been changed to use this
functionality instead of implementing it with a special
build item.

The new property
abuild.include-ant-runtime has been
added to include ant's runtime
libraries in your compilation class path. This removes the
need to access ANT_HOME (and therefore
require it to be set) when compiling custom ant tasks.

Boolean Abuild.interface variables are
now converted to “1” and
“0” for
ant-based builds just as they
are for make-based builds.
Earlier versions of abuild used
“1” and
“0” for
make-based builds and
“yes” and
“no” for
ant-based builds.

Make/C/C++ Changes

Abuild now supports the creation of shared library files
on UNIX platforms and DLL files on Windows platforms. It
also compiles all library files as position-independent
code. Users wishing to take advantage of this new
functionality are recommended to rebuild from a clean
state.

It is now possible to generate the preprocessed version of
any C or C++ source file by running abuild
SourceFile.i.

The old dummymake rules, never previously
documented, have been renamed to empty
and are now documented and officially supported.

The texinfo rules have been removed.

1.0.a20: September 4, 2007

Configuration changes

Writable backing areas are no longer supported; all backing
areas are read only. The
Abuild.backing file now contains only
the path name of the backing area.

Added new deleted key to
Abuild.conf, making it possible to make
build items in a backing area that are not present in the
local tree inaccessible.

Invocation changes

Platform selection criteria are now supported via the
--platform-selector or
-p command-line option and the
ABUILD_PLATFORM_SELECTORS environment
variable. This makes it possible to more tightly control
which platforms will be built. Along with this, the option
field, formerly known as the flags field, of object code
platforms is implemented along with a recommended method for
generating release and debug builds.

The all build set no longer ever builds
items in backing areas since all backing areas are now read
only. The local build set no longer
builds externals. If you wish to build the local tree and
its externals as well, use the all build
set. This makes the local build set do
what people always thought it did anyway.

The --list-platforms command-line
argument lists all known object-code platforms grouped by
platform type.

The command abuild --dump-data will now
attempt to generate dump data output even when there were
errors. This makes it possible to use the dump data output
to help figure out what may be causing the errors. The
errors attribute will be present and
have the value 1 when errors have been
detected.

Added --monitored flag to put abuild into
monitored mode. This is primarily intended to support
front-ends to abuild that want to monitor progress. For
information, see Chapter 31, Monitored Mode.

Abuild's choice of backend is no longer determined by the
target type of the build item but is instead determined by
the type of build file it has. This change is invisible to
users of older versions of abuild as it will always do the
same thing for any existing configurations. It does, in
principle, make it possible to use ant for C/C++ builds and
make for Java-based builds, provided the proper support code
was added, and it also opens the door for supporting a wider
array of backends.

In many error messages, relative paths to
Abuild.conf files have been replaced
with absolute paths.

Make changes

The BI_RULES variable has been renamed to
BUILD_ITEM_RULES. A deprecation warning
will be issued if BI_RULES is used. This
backward compatibility will be removed before 1.0.

New documented flags have been added to
ccxx.mk. These changes are mostly
user-invisible, but end user Abuild.mk
files that set the DFLAGS make variable
will need to be changed.

Previously undocumented toolchain-specific make flags
variables have been removed in favor of using conditionals
based on $(CCXX_TOOLCHAIN).

ccxx.mk has been reworked somewhat to
make it easier to write new compiler support files and to
simplify overriding of debug, optimization, and warning
flags. These changes are invisible to the vast majority of
end-user Abuild.mk files but have a
significant impact on toolchain support files, which prior
to this release, were all included in abuild anyway. The
ccxx.mk file itself is heavily
commented.

Java changes

An alternative for Java builds has been provided. In this
alternative, you can write your own
build.xml files with some minor
limitations.

Non-compatible change: there is now
only one java platform, java. The
interface variable
abuild.platform.bytecode is no longer
defined. Abuild no longer attempts to manage different java
bytecode versions itself. However, two new properties:
abuild.source-java-version and
abuild.target-java-version can now be set
in Abuild-ant.properties. This change
is invisible to people who did not either access the
abuild.platform.bytecode variable or the
abuild-java5 path.

Bug fix: abuild will now work properly if
$(ANT_HOME) points to a path with a space
it in.

Platform changes

There is no longer support for nested platform types. All
the operating system-specific platform types
(unix, windows,
etc.) have been removed. This is not a user-visible change
since there were never any platforms in those platform
types. Note that new platforms and platform types may now
be added in plugins.

Abuild's internal list_platforms command
has moved from private/bin to
private and generates new kinds of
output. Abuild's own bootstrapping uses
private/bin/bootstrap_native_platform.

Full cross-platform dependency support is fully implemented.
It is now possible to mention a platform type and platform
selection criteria on a dependency declaration using the
-platform option in the
deps key in
Abuild.conf.

The USE_MSVC environment variable is no
longer required for using Visual C/C++. Instead, abuild
will try to use it if the VCINSTALLDIR
variable is set. Based on Microsoft documentation, this
appears to be a reliable test that the appropriate Visual
Studio variables are in the environment.

--dump-data changes

Since writable backing areas are no longer supported, there
is no longer a writable attribute to the
backing-area element.

The platform-data element has been added.
This gives overall platform information as well as
build-tree-specific platform information.

The deleted-items element has been added
to build-tree.

Several attributes and elements have been added because of
plugin support. In particular, the
is-plugin and
is-plugin-anywhere attributes have been
added to build-item, the
has-shadowed-dependencies attribute has
been changed to has-shadowed-references
and is also true if plugins are shadowed, and the new
plugins element has been added.

The new attribute external-depth has been
added to build-item. Items local to the
build tree from which abuild was started are now
detectable by having both external-depth
and backing-depth equal to
0. (They can, as before, also be
detected by having their home tree be the current build
tree.)

With full cross-platform dependencies supported, the
dependency element now has an optional
platform-type attribute.

The build-platforms and
known-platforms attributes have been
removed from build-item, and the
buildable-platforms attribute has been
added.

1.0.a19: July 31, 2007

Java changes

Non-compatible change: Previously
undocumented ear-contents and
war-classpath directories are no longer
used. New documented classpath
directory has been introduced for use in copying classpath
files into archives. This mechanism may change in the
future.

Non-compatible change: It is no longer
possible to create a local JAR file in the same build item
as an EAR file. The EAR example in the Java Archive Types
example has been updated to illustrate a different way to do
this.

Non-compatible change: For WAR build
items, the property abuild.war-type must
now be set to either client or
server.

It is now possible to add arbitrary files to an EAR file and
to populate an EAR file's META-INF
directory.

New functionality

The new --print-abuild-top flag has been
added to print the name of the abuild's installation
directory.

Non-compatible change: the
autofiles statement in
Abuild.interface has been changed to
after-build to more accurately reflect
its purpose and functionality.

Interface flags are now supported. Build items can declare
supported flags in their Abuild.conf
files and can reference those flags in their
Abuild.interface files. They can also
specify which flags should be set for other build items in
their direct dependency list.

Non-compatible change: in light of the
introduction of interface flags,
BI_PRIVATE and
Private.mk are no longer supported.
The private interface example illustrates how to support
this construct in a cleaner way using interface flags.

Build item traits are now supported. This allows build
items to be grouped based on functionality or relationships
to other build items that fall outside of the dependency
graph.

Several examples in the documentation have been updated to
demonstrate new functionality. Some new examples have also
been added.

It is now possible to reset a variable in
Abuild.interface using the
reset, reset-all, and
no-reset statements. Please see the
relevant sections of the document to understand how these
work and the subtleties of their use.

Externals that are resolved through backing areas now appear
in the --dump-data output with the
backed="1" attribute. Before, they did
not appear at all.

Information about traits and flags have been added to
--dump-data output.

All whitespace-separated lists have been removed from
--dump-data output and have been replaced
by nested elements instead. This made room for inclusion of
flag and trait information in the dump data output and also
makes it easier for applications to parse the XML.

Bug fixes

Incorrect regular expression could cause “memory
exhausted” to be printed when certain syntax errors
appeared in Abuild.conf files.

Several cases involving whitespace handling were fixed in
the interface parser. Specifically, the following patterns
could result in parse errors: trailing whitespace at the end
an interface file without a line terminator, a continuation
character in a file with Windows-style newlines, and a
continuation character followed by a line that did not start
with a space.

Path comparison on Windows is now case-insensitive when
computing one path relative to another. When asking for one
path relative to a path on a different drive, the first path
is returned unchanged. This should make abuild itself able
to use backing areas on different drives, though this case
has not been thoroughly tested.

Short forms of command-line options added in 1.0.a14 have
been added to abuild --help's output.

1.0.a18: July 18, 2007

Run junit tests with fork="true" for better
performance.

Support added for WAR files.

The src/java directory is now optional.
It makes sense to omit it for some WAR files as well as for
JAR files that consist entirely of resources or automatically
generated code.

In order to support a wider range of java archive types, the
abuild.jar-name and
abuild.ear-name properties in
Abuild-ant.properties must now include
the filename extension of the archive file.

1.0.a17: July 9, 2007

Implemented new build item accessibility scheme that allows
nested namespace scopes. To upgrade your build item names,
please run misc/upgrade-scope-names from
the abuild installation directory. Two consecutive dashes
(--) no longer has any special meaning in
build item names. Abuild also no longer requires the
public parent of a private build item to exist. For details
on the new accessibility system, see Section 6.3, “Build Item Name Scoping”.

Added optional visible-to field to the
Abuild.conf file to allow build items to
expand their visibility as otherwise restricted by the new
scoping rules. This is also an optional attribute to
BuildItem in the
--dump-data output.

Added “mixed classification” example to the
complete example section. This shows a pattern of how one
might organize build items in a mixed classification
environment. It also shows a real-world application of the
new visible-to field in the
Abuild.conf file.

Added an optional description field to
Abuild.conf. This is for informational
use only. It appears in the --dump-data
output if present.

Run pre- and post- compile and package hooks in Java even if
the compile and package targets are not being run. This makes
it possible to, for example, generate wrappers from
post-package hooks even if no packages are being created. The
Java example has been enhanced to illustrate this case.

Bug fix: autoconf rules have been modified slightly so that
they should work properly when --make-jobs
is used.

Added cygwin as a valid platform type as distinct from
Windows. Although abuild should in principle work just fine
if compiled as a cygwin application, this has not been tested
and there is no intention of actually supporting it. However,
there's also no good reason to hard-code into abuild the idea
that when cygwin is present, it means Windows, not cygwin.

Change layout of source directory: manual sources are now in
src/manual and dump data DTD is now in
the src directory. The compiled manual
in PDF and HTML formats along with the DTD are included in the
doc directory in the binary distribution.

1.0.a16: June 22, 2007

Abuild no longer has to be in a directory called
abuild. Instead, it looks above the full
path of the abuild executable for a directory that contains
make/abuild.mk. This means it's possible
to install abuild under a directory named
abuild-version, for
example.

The ant package target has been recoded to
avoid multiple invocations of the compile
target.

A small error was corrected in
abuild_data.dtd. A test case has been
added to ensure that it is always accurate in future releases.

1.0.a15: June 18, 2007

Basic Java support has been added.

Add -mlongcall to vxworks compilation

The documentation has been reorganized somewhat for greater
clarity. The contents of the example files have been moved to
an appendix at the back of the document which makes them
easier to separate when going through examples.

A standard doc target has been added,
though it does not yet do anything for make-based target types

The test and check
targets are now identical in functionality. It used to be
that test did not depend on all, but this
is no longer the case.

Abuild now looks in the qtest directory
rather than the tests for qtest test
suites.

Environment variables may now appear in interface files using
the syntax $(ENV:VARIABLE). Use sparingly.

When cleaning with a clean set, items that have no build files
are skipped.

The -- argument has been dropped in favor
of --make and --ant
options which pass arguments specifically to make or ant.
Both options can be specified so that a mixed build can pass
different arguments to make and to ant.

The style of element names used in
--dump-data has been changed from
ThisStyle to this-style

There is no longer a default value for the
platform-types key in
Abuild.conf. The
upgrade-interfaces script that assists
with upgrading from pre-1.0.a14 versions of abuild will create
values when necessary based on the old rules.

Short forms of --build=set,
--clean=set, and
--with-deps options have been provided.
See command line syntax for details.

Clean sets are no longer automatically expanded to include
recursively expanded dependencies. The
deps and current
build/clean sets have been redefined to explicitly include
expanded dependencies and therefore have no change of
semantics. The main result of this change is that running
--clean=desc now no longer ever cleans
anything not below the directory from which abuild was
invoked.

The option to pass VAR=value arguments to
abuild and to have those passed on to make has been removed.
If you need to do this, place these arguments after
--, since all those arguments are passed
directly to the backend anyway.

The documentation was updated to accurately reflect recent
changes of platform handling, the new interface system, and
refactoring that was performed during the C++ port.

Implementation of completely new interface system. Interfaces
now use Abuild.interface instead of
Interface.mk. The new interface files
are loaded internally by abuild and are no longer tied to GNU
Make.

Remove Windows-only XLIBS interface
variable. Instead of appending xyz to
XLIBS, append xyz.lib
to XLINKFLAGS. (Note: in a later change,
we now recommend using LIBS and LIBDIRS for third-party
libraries just as you would for your own libraries.)

Terminology change: “architecture” is now
“platform”, “architecture category” is
now “platform type”, and “architecture
class” is now “target type.” The
arch key in
Abuild.conf is now
platform-types. The
archclass key in
Abuild.interface is now
target-type.

Changes to platform identifiers: this release includes an
early implementation of the new
os.cpu.toolset.compiler[.flags] format.

The vc7 C/C++ toolchain is now called
msvc since it works with Visual C++
version 8 as well as version 7. The environment variable
USE_MSVC, rather than USE_VC7, now selects it.

1.0.a13: May 1, 2007

Abuild, previously implemented in Perl, was rewritten in C++.

For compilers that support it, gen_deps is bypassed in favor
of the compiler's internal dependency generation capabilities.
This will improve build performance for those compilers. As
of 1.0.a13, the only compiler that produces exactly what
abuild needs is gcc.

The default optimization for gcc and xlc has been changed from
-O3 to -O2 as many people have reported problems with -O3.
For most cases, -O3 will not make a big difference in
performance, but there are some cases in which it can be a
significant difference. For those cases, it is still possible
to override this for individual files or individual build
items if desired.

Abuild no longer provides the variables
abHOST_ARCH, abHOST_OS,
abHOST_DIST, or
abHOST_CPU as they did not previously
contain reliably useful values and were never documented.

When looking for GNU Make, abuild now checks all occurrences
of gmake and then of make in the path, stopping with the first
one that appears to be GNU Make version 3.81 or newer. It
previously checked only the first occurrence of make or gmake
and required that occurrence to be GNU Make 3.81 or newer.

Abuild now only checks for GNU Make if at least one build item
requires it.

Abuild no longer calls umask 002 before starting to build.
This means that it will not create group-writable files unless
the calling user's umask is set appropriately. The old
behavior of calling umask 002 was a vestige of the past when
it was common for multiple users to be building in the same
directory. Although this may sometimes still be desirable,
it's not the place of abuild to override the user's umask
setting.

Starting in version 1.0.a11, abuild no longer creates
.ab-dynamic.mk outside of architecture
directories. Versions 1.0.a11 and 1.0.a12 deleted stray
.ab-dynamic.mk files created by older
versions of abuild. This version no longer does. If you
are upgrading from a version older than 1.0.a11, you should
manually remove any .ab-dynamic.mk files
that are left lying around. Since abuild automatically
creates those that it needs on each run, running
find . -name .ab-dynamic.mk -exec rm {} \;
will do the job.

The --host-arch command line argument was
removed.

1.0.a12: April 2, 2007

It is now possible to specify that a library should be linked
in its entirety by defining the variable
WHOLE_lib_libname for library
libname in the
Interface.mk file that provides
libname. For systems that use the gnu
linker, this results in the --whole-archive
flag being used for the specified library. Note that not all
systems support this feature, so this behavior should not be
relied upon when not absolutely necessary.

1.0.a11: March 30, 2007

Move XLINKFLAGS to the end of the link step
(after LIBS) for all C/C++ compilers.

The -j flag now controls how many build
items abuild will attempt to build in parallel and is no
longer passed to make. The new command-line option
--make-jobs can be used to pass the
-j flag to make.

Abuild no longer uses any recursion at all. Rather than
having a top-level abuild process invoke subsidiary abuild
processes for specific builds, abuild computes all the
directories in which builds will be run and invokes the
backend directly in each directory. Abuild now manages all of
its build order computations and parallelism computations
itself rather than relying on GNU Make. This means that
abuild now uses GNU Make only for performing the actual
compiles, which greatly simplifies abuild's make code and
makes it much more able to support alternative backends. A
pleasant side effect of this change is that abuild runs much
more quickly and no longer needs to cache any information. A
version of abuild to appear in the very near future will
change the mechanism through which build items publish their
build interfaces, eliminating
Interface.mk and replacing it with some
other mechanism.

Abuild no longer creates .abuild-cache.*
directories at all and also no longer creates
.ab-dynamic.mk files outside of
architecture subdirectories.

1.0.a10: March 26, 2007

Various Windows portability fixes including changing cache
file names to make them shorter.

Deprecated debugging flag removed from VC7 toolchain support
file.

Abuild now works when run via a symbolic link. In other
words, it now works to add a symlink called abuild in your
path and have it point to the real abuild. If you attempted
to do this in prior versions, you would get an error because
abuild would not be able to find its data files.

The support test framework is now called
qtest, and the name of its driver is
qtest-driver. Abuild has been updated
with the new name information.

Bug fix: abuild was previously invoking qtest-driver in a
manner such that test coverage files would never been seen.
This is now fixed. (Requires the qtest version >= 1.0.a1 as
well.)

1.0.a9: March 14, 2007

Use $WIND_HOME instead of
/opt/WindRiver to find the vxworks
toolchain.

1.0.a8: March 13, 2007

Change the hacked vxworks support to be just a little bit less
hacked. Abuild no longer uses the hacked toolchain on hydra1;
it now recognizes the vendor-supplied cross compiler toolchain
if installed in /opt/WindRiver, resulting
in working C++ support for a Linux Intel to vworks ppc cross
compilation. This is still a temporary solution, but it is
closer to the real thing.

1.0.a7: March 7, 2007

Make a few changes to the temporary vxworks support to allow
C++ compilation to succeed.

1.0.a6: March 6, 2007

Abuild now loads Interface.mk files in
forward rather than reverse dependency order. In order to
avoid having to change all the
Interface.mk files to ensure that library
ordering is still correct, special case code has been added to
handle the INCLUDES,
LIBS, and LIBDIRS
variables. This turned out to be a temporary solution, as
hoped. For a detailed description of this change, please see
the 1.0.a6 documentation.

Abuild now loads the C/C++ toolchain configuration before
loading any architecture-specific rules. This means that the
autoconf rules will know the proper C/C++
toolchain even if the ccxx rules are not
also loaded.

Bug fix: some of the XCFLAGS-like variables
were not being used at all the right places after the
refactoring of the toolchain support.

Change VxWorks support so that library targets build normal
.a files and executable targets build
.out files that can link with libraries.
This is still not necessarily the final way it's going to
work.

1.0.a3: February 20, 2007

Fix .LIBPATTERNS warning on VxWorks

Detect when a build set contains no buildable items and exit
cleanly without attempting to build.

1.0.a2: February 19, 2007

The strings as C or as
C++ are included in abuild's output when compiling C
and C++ respectively.

Internal make directory has been
reorganized. The two changes that affect the documentation
are that make/rules/arch-indep is now
make/rules/indep and
make/rules/arch-dep is now
make/rules/archdep. Other changes were
also made.

Hacked in support for xlc (IBM compiler) and vxworks. The xlc
and vxworks are specific to a particular configuration and
will disappear in a future release when a suitable facility is
added for extending abuild with external rules.

The beginning of multiple architecture support has been
implemented. It now works to set arch in
Abuild.conf to native
vxworks to build for both the native platform and
for VxWorks or to set it to vxworks to
build for VxWorks only. The rest of the documentation has not
been updated to reflect this yet.

1.0.a1: February 8, 2007

Separate specification of private interfaces are now supported
through use of the Private.mk file.
(This mechanism was changed in a later release.)

Abuild now enforces that BI_RULES in
Abuild.mk may not contain inaccessible
private build items.