11be35a165
To do so, a few dependencies have been imported: * external/bsd/lutok * external/mit/lua * external/public-domain/sqlite * external/public-domain/xz The Kyua framework is the new generation of ATF (Automated Test Framework), it is composed of: * external/bsd/atf * external/bsd/kyua-atf-compat * external/bsd/kyua-cli * external/bsd/kyua-tester * tests Kyua/ATF being written in C++, it depends on libstdc++ which is provided by GCC. As this is not part of the sources, Kyua is only compiled when the native GCC utils are installed. To install Kyua do the following: * In a cross-build enviromnent, add the following to the build.sh commandline: -V MKBINUTILS=yes -V MKGCCCMDS=yes WARNING: At this point the import is still experimental, and not supported on native builds (a.k.a make build). Change-Id: I26aee23c5bbd2d64adcb7c1beb98fe0d479d7ada
114 lines
3.9 KiB
Groff
114 lines
3.9 KiB
Groff
.\" Copyright 2012 Google Inc.
|
|
.\" 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.
|
|
.Dd September 9, 2012
|
|
.Dt KYUA-BUILD-ROOT 7
|
|
.Os
|
|
.Sh NAME
|
|
.Nm build-root
|
|
.Nd Mechanics of build directories
|
|
.Sh DESCRIPTION
|
|
.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.
|
|
.Pp
|
|
Most build systems today support build directories. For example, the GNU
|
|
Automake/Autoconf build system exposes such concept when invoked as
|
|
follows:
|
|
.Bd -literal -offset indent
|
|
$ cd my-project-1.0
|
|
$ mkdir build
|
|
$ cd build
|
|
$ ../configure
|
|
$ make
|
|
.Ed
|
|
.Pp
|
|
Under such invocation, all the results of the build are left in the
|
|
.Pa my-project-1.0/build/
|
|
subdirectory while maintaining the contents of
|
|
.Pa my-project-1.0/
|
|
intact.
|
|
.Pp
|
|
Because build directories are an integral part of most build systems, and
|
|
because they are a tool that developers use frequently,
|
|
.Xr kyua 1
|
|
supports build directories too. This manifests in the form of
|
|
.Xr kyua 1
|
|
being able to run tests from build directories while reading the (often
|
|
immutable) test suite definition from the source tree.
|
|
.Pp
|
|
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:
|
|
.Bd -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
|
|
.Pp
|
|
Note how the directory layout within
|
|
.Pa src/
|
|
matches that of
|
|
.Pa obj/ .
|
|
The
|
|
.Pa src/
|
|
directory contains only source files and the definition of the test suite
|
|
(the Kyuafiles), while the
|
|
.Pa obj/
|
|
directory contains only the binaries generated during a build.
|
|
.Pp
|
|
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
|
|
.Xr kyua-test 1
|
|
as any of the following:
|
|
.Bd -literal -offset indent
|
|
$ kyua test --kyuafile=src/Kyuafile --build-root=obj
|
|
$ cd src && kyua test --build-root=../obj
|
|
.Ed
|
|
.Sh SEE ALSO
|
|
.Xr kyua 1 ,
|
|
.Xr kyua-debug 1 ,
|
|
.Xr kyua-list 1 ,
|
|
.Xr kyua-test 1
|