diff options
| -rw-r--r-- | doc/manual.cli | 36 |
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 |