Abuild's backends define several targets that are available for use from the command line, so you can rely on these targets being defined. [28]
This is the default target. It is used to build all products that are intended for use by the end user or by other build items.
This target ensures that the local build item is built and then runs its automated test suite, if any. For this to do anything, the build item must have a test suite implemented with a test framework that is integrated with abuild or that is made available with a plugin. Abuild is integrated with QTest and, for Java-based build items, also with JUnit. The check target is not automatically run by the default target; it must be requested specifically.
This target removes any output directories that abuild
thinks it created. (Output directories are discussed in Section 5.3, “Output Directories”.) Well-behaved abuild
rules, including all the rules that are a standard part of
abuild, won't create any files or directories outside of
these locations. See also the description of the
--clean-platforms
(in Section 13.4, “Control Options”) to learn about
restricting which platform directories are removed.
This target is provided for building documentation that is
extracted from source code. The doc target
is not automatically run by the default target; it must be
requested explicitly. It depends on the
all target. There is no internal support
for document generation in the make
backend, so this capability must be provided by a plugin. For
Groovy/ant builds, there is
built-in support for javadoc, but it is minimal and will
likely have to be supplemented for any major documentation
effort. A contributed plugins to support doxygen is available
in abuild-contrib
, which is released
separately from abuild.
This target does nothing other than printing the name and
platform of each build item in the build set, but using it
still causes abuild to perform all the same validations it
would perform if it were going to build something. The
no-op target can be used to get a complete
list of all the items and platforms that would be built if
building a given build set and will also verify that there are
no errors in any Abuild.conf
files. Note
that Abuild.interface
files are not read
when invoking the no-op target.
This target is a synonym for check.
This target runs any automated test suites but does not first try to build. In other words, the test-only target does not depend on the all target like the check and test targets do. This can be useful for running a test suite on a build item without first rebuilding it or for running all the test suites on a build tree that you know is up to date because you just built it.
[28]
When the Abuild-ant.xml
build file is used
with the deprecated xml-based ant backend, it is up to the
author of the build file to provide these targets, and all bets
are off.