13.7. General Targets

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.