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.

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”.

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.

Platform types may now have parents, which makes it possible to make some platform types specializations of other platform types. This is discussed in Section 24.2, “Dependencies and Platform Compatibility”. Three sections of the documentation have been significantly updated based on this change: Chapter 24, Cross-Platform Support, Section 29.3.1, “Adding Platform Types”, and Section 33.6, “Construction of the Build Graph”.

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”.

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.

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.

Abuild is now able to capture the output of builds and associate each line of output with the build item that produced it. For additional details, please see Chapter 20, Controlling and Processing Abuild's Output.

It is now possible to have abuild prefix every line of normal output and/or every line of error output with fixed prefixes. For details, see Chapter 20, Controlling and Processing Abuild's Output.

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.

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.

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.

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.

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.

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.

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.

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.

Initialize ant Project properly so that tasks using the deprecated xml-based ant framework can properly access System.in.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.)

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.

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.

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.

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.

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.

New make variables have been added for increasing the flexibility of configuring Visual C++. See Section 18.2.2, “Options for the msvc Compiler”.

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.

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.

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.

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

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 level can be set using the ABUILD_COMPAT_LEVEL environment variable in addition to use the --compat-level command line argument.

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).

For a brief summary of changes in the new build tree structure, please refer to Section B.5, “Redesigned Build Tree Structure”.

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.

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.

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-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 os cpu toolset

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:

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.

No features have been deprecated in this release.

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.

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.

No features have been deprecated in this release.

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.

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]

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

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

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.)

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.

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.

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 variable type = initialization

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Abuild no longer automatically removes stray automatically generated files created by versions older than 1.0.a14.

Abuild no longer accepts BI_RULES as a synonym for BUILD_ITEM_RULES.

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.

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.

Abuild interface variable ABUILD_PLATFORM_TYPE is now defined.

A program is now provided to verify proper operation of compiler plugins. (See Section 29.4, “Adding Toolchains”.)

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.

A new example has been created to illustrate how to pass information safely from a make variable to your source code. See Section 22.5, “Dependency on a Make Variable”.

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.)

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.

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.

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.

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.

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.

New name and pattern based build sets have been added. See Section 9.2, “Build Sets” for details.

--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.

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.

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 dummy make rules, never previously documented, have been renamed to empty and are now documented and officially supported.

The texinfo rules have been removed.

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.

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.

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.

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.

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.

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.

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.

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.

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.