Update manual with new build configuration naming

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