aboutsummaryrefslogtreecommitdiff
path: root/doc/manual.cli
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2018-12-03 08:22:15 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2018-12-03 08:22:15 +0200
commit2aaebd8d3ae370923790b0181cfb12b6cb01b648 (patch)
tree33b536d6d4c9194540d81e04c4a60ee440ac3397 /doc/manual.cli
parent5d15fd7717b9b797e04e0656866b1a94d181dd73 (diff)
Update manual with new build configuration naming
Diffstat (limited to 'doc/manual.cli')
-rw-r--r--doc/manual.cli36
1 files changed, 19 insertions, 17 deletions
diff --git a/doc/manual.cli b/doc/manual.cli
index 8584910..0c4808a 100644
--- a/doc/manual.cli
+++ b/doc/manual.cli
@@ -87,7 +87,7 @@ and a \i{build configuration}. The machine configuration captures the
operating system, installed compiler toolchain, and so on. The same build
machine may be used to \"generate\" multiple \i{build configurations}. For
example, the same machine can normally be used to produce 32/64-bit and
-debug/release builds.
+debug/optimized builds.
The machine configuration is \i{approximately} encoded in its \i{machine
name}. The machine name is a list of components separated with \c{-}.
@@ -122,7 +122,7 @@ The second component normally identifies the installed compiler toolchain and
has the following recommended form:
\
-<id>[<version>][<runtime>]
+<id>[<version>][<vendor>][<runtime>]
\
For example:
@@ -131,6 +131,7 @@ For example:
gcc
gcc_6
gcc_6.3
+gcc_6.3_mingw_w64
clang_3.9_libc++
clang_3.9_libstdc++
msvc_14
@@ -142,7 +143,7 @@ Some examples of complete machine names:
\
windows_10-msvc_14u3
-macos_10.12-clang
+macos_10.12-clang_10.0
linux_ubuntu_16.04-gcc_6.3
\
@@ -150,12 +151,13 @@ Similarly, the build configuration is encoded in a \i{configuration name}
using the same format. As described in \l{#arch-controller Controller Logic},
build configurations are generated from machine configurations. As a result,
it usually makes sense to have the first component identify the operating
-systems and the second component \- the toolchain with the rest identifying
-a particular build configuration. For example:
+systems and the second component \- the toolchain with the rest identifying a
+particular build configuration variant, for example, optimized, sanitized,
+etc. For example:
\
-windows-vc_14-32-debug
-linux-gcc_6-cross-arm-eabi
+windows-vc_14-O2
+linux-gcc_6-O3_asan
\
\h#arch-machine-header|Machine Header Manifest|
@@ -894,18 +896,18 @@ testing its packages with this machine). If multiple machines match the same
pattern, then only a single configuration using any of the machines is
produced (meaning that this controller considers these machines equivalent).
-As an example, let's say we have a machine named \c{windows_10-vc_14u3}. If
-we wanted to test both 32 and 64-bit builds as well as debug and release, then
+As an example, let's say we have a machine named \c{windows_10-vc_14u3}. If we
+wanted to test both 32 and 64-bit as well as debug and optimized builds, then
we could have generated the following configurations:
\
-windows*-msvc_14* windows-msvc_14-32-debug i686-microsoft-win32-msvc14.0 \"all default msvc i686\" config.cc.coptions=/Z7 config.cc.loptions=/DEBUG ~\"warning C4\d{3}: \"
+windows*-msvc_14* windows-msvc_14-32-Z7 i686-microsoft-win32-msvc14.0 \"all default msvc i686 debug\" config.cc.coptions=/Z7 config.cc.loptions=/DEBUG ~\"warning C4\d{3}: \"
-windows*-msvc_14* windows-msvc_14-32-release i686-microsoft-win32-msvc14.0 \"all default msvc i686 optimized\" config.cc.coptions=/O2 ~\"warning C4\d{3}: \"
+windows*-msvc_14* windows-msvc_14-32-O2 i686-microsoft-win32-msvc14.0 \"all default msvc i686 optimized\" config.cc.coptions=/O2 ~\"warning C4\d{3}: \"
-windows*-msvc_14* windows-msvc_14-64-debug x86_64-microsoft-win32-msvc14.0 \"all default msvc x86_64\" config.cc.coptions=/Z7 config.cc.loptions=/DEBUG ~\"warning C4\d{3}: \"
+windows*-msvc_14* windows-msvc_14-64-Z7 x86_64-microsoft-win32-msvc14.0 \"all default msvc x86_64 debug\" config.cc.coptions=/Z7 config.cc.loptions=/DEBUG ~\"warning C4\d{3}: \"
-windows*-msvc_14* windows-msvc_14-64-release x86_64-microsoft-win32-msvc14.0 \"all default msvc x86_64 optimized\" config.cc.coptions=/O2 ~\"warning C4\d{3}: \"
+windows*-msvc_14* windows-msvc_14-64-O2 x86_64-microsoft-win32-msvc14.0 \"all default msvc x86_64 optimized\" config.cc.coptions=/O2 ~\"warning C4\d{3}: \"
\
As another example, let's say we have \c{linux_fedora_25-gcc_6} and
@@ -913,9 +915,9 @@ As another example, let's say we have \c{linux_fedora_25-gcc_6} and
builds on Linux, then our configurations could look like this:
\
-linux*-gcc_6 linux-gcc_6-debug x86_64-linux-gnu \"all default gcc\" config.cc.coptions=-g
+linux*-gcc_6 linux-gcc_6-g x86_64-linux-gnu \"all default gcc debug\" config.cc.coptions=-g
-linux*-gcc_6 linux-gcc_6-release x86_64-linux-gnu \"all default gcc optimized\" config.cc.coptions=-O3
+linux*-gcc_6 linux-gcc_6-O3 x86_64-linux-gnu \"all default gcc optimized\" config.cc.coptions=-O3
\
If the \c{<config-arg>} list contains the \c{config.install.root} variable
@@ -938,9 +940,9 @@ As an example, the following two configurations could be used to test system
and private installations:
\
-linux*-gcc* linux-gcc-sys x86_64-linux-gnu \"all default gcc\" config.install.root=/usr config.install.sudo=sudo
+linux*-gcc* linux-gcc-sysinstall x86_64-linux-gnu \"all default gcc\" config.install.root=/usr config.install.sudo=sudo
-linux*-gcc* linux-gcc-prv x86_64-linux-gnu \"all default gcc\" config.install.root=/tmp/install config.cc.poptions=-I/tmp/install/include config.cc.loptions=-L/tmp/install/lib config.bin.rpath=/tmp/install/lib
+linux*-gcc* linux-gcc-prvinstall x86_64-linux-gnu \"all default gcc\" config.install.root=/tmp/install config.cc.poptions=-I/tmp/install/include config.cc.loptions=-L/tmp/install/lib config.bin.rpath=/tmp/install/lib
\
Note also that while building and running tests against the installation the