All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of Google Inc. nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.Em Build directories (or object directories, target directories, product directories, etc.) is the concept that allows a developer to keep the source tree clean from build products by asking the build system to place such build products under a separate subtree.
p Most build systems today support build directories. For example, the GNU Automake/Autoconf build system exposes such concept when invoked as follows: d -literal -offset indent $ cd my-project-1.0 $ mkdir build $ cd build $ ../configure $ make .Ed
p Under such invocation, all the results of the build are left in the
a my-project-1.0/build/ subdirectory while maintaining the contents of
a my-project-1.0/ intact.
p Because build directories are an integral part of most build systems, and because they are a tool that developers use frequently, .Nm supports build directories too. This manifests in the form of .Nm being able to run tests from build directories while reading the (often immutable) test suite definition from the source tree.
p One important property of build directories is that they follow (or need to follow) the exact same layout as the source tree. For example, consider the following directory listings: d -literal -offset indent src/Kyuafile src/bin/ls/ src/bin/ls/Kyuafile src/bin/ls/ls.c src/bin/ls/ls_test.c src/sbin/su/ src/sbin/su/Kyuafile src/sbin/su/su.c src/sbin/su/su_test.c obj/bin/ls/ obj/bin/ls/ls* obj/bin/ls/ls_test* obj/sbin/su/ obj/sbin/su/su* obj/sbin/su/su_test* .Ed
p Note how the directory layout within
a src/ matches that of
a obj/ . The
a src/ directory contains only source files and the definition of the test suite (the Kyuafiles), while the
a obj/ directory contains only the binaries generated during a build.
p All commands that deal with the workspace support the .Fl -build-root Ar path option. When this option is provided, the directory specified by the option is considered to be the root of the build directory. For example, considering our previous fake tree layout, we could invoke .Nm as any of the following: d -literal -offset indent $ kyua __COMMAND__ --kyuafile=src/Kyuafile --build-root=obj $ cd src && kyua __COMMAND__ --build-root=../obj .Ed