Version 0.6.0 * C++ Modules TS support for GCC, Clang, and VC. The new 'experimental' value of the cxx.std variable enables modules support if provided by the C++ compiler. The cxx.features.modules boolean variable can be used to control/query C++ modules enablement. See the "C++ Module Support" section in the build system manual for all the details. * Precise change detection for C and C++ sources. The build system now calculates a checksum of the preprocessed token stream and avoids recompilation if the changes are ignorable (whitespaces, comments, unused macros, etc). To minimize confusion ("I've changed my code but nothing got updated"), the build system prints a 'skip' line for ignored changes. * Initial support for utility libraries. A utility librart is an archive that "mimics" the object file type (executable, static library, or shared library) of its "primary" target. Unless explicitly overridden, utility libraries are linked in the "whole archive" mode. For example: exe{prog}: cxx{prog} libu{prog} libu{prog}: cxx{* -prog} libu{prog} # Unit tests. # tests/ { libu{*}: bin.whole = false # Don't link whole. exe{test1}: cxx{test1} ../libu{prog} exe{test2}: cxx{test2} ../libu{prog} } This change adds the new target group libu{} and its libue{}, libua{}, and libus{} members. Note that the bin.whole variable can also be used on normal static libraries. * Progress display. The build system will now display build progress for low verbosity levels and if printing to a terminal. It can also be explicitly requested with the -p|--progress option and suppressed with --no-progress. Note that it is safe to enable progress even when redirecting to a file, for example: b -p 2>&1 | tee build.log * Support for generating pkg-config's .pc files on install. These files are now generated by default and automatically for libraries being installed provided the version, project.summary, and project.url variables are defined. The version module has been improved to extract the summary and url in addition to version from the manifest. * Support for the '20' cxx.std value (C++20/c++2a). * The fail, warn, info, and text directives in addition to print. For example: if ($cxx.id.type == 'msvc') fail 'msvc is not supported' * New build system functions: - $getenv() -- query environment variable value - $filesystem.path_{search,match}() -- wildcard pattern search/match - $regex.{match,search,replace}() -- regex match/search/replace * New Testscript builtins: - ln - exit (pseudo-builtin) * Separate C and C++ (partial) preprocessing and compilation for Clang, GCC, and VC. This is part of the infrastructure that is relied upon by the C++ modules support, precise change detection support, and, in the future, by distributed compilation. There is also the ability to limit the amount of preprocessing done on a source file by setting the {c,cxx}.preprocessed variables. Valid values are 'none' (not preprocessed), 'includes' (no #include directives in the source), 'modules' (as above plus no module declarations depend on the preprocessor, for example, #ifdef, etc.), and 'all' (the source is fully preprocessed). Note that for 'all' the source may still contain comments and line continuations. While normally unnecessary, the use of the (partially) preprocessed output in compilation can be disabled. This can be done from a buildfile for a scope (including project root scope) and per target via the cc.reprocess variable: cc.reprocess = true obj{hello}: cc.reprocess = false As as well externally via the config.cc.reprocess variable: b config.cc.reprocess=true Version 0.5.0 * Parallel build system execution, including header dependency extraction and compilation. * Support for Testscript, a shell-like language for portable and parallel execution of tests. See the Testscript manual for details. * Support for name generation with wildcard patterns. For example: exe{hello}: cxx{*} Or: ./: {*/ -build/} See the build system manual for details. * New module, version, automates project version management. See the build system manual for details. * Support for VC15, C++ standard selection in VC14U3 and up. * New meta-operation, create, allows the creation and configuration of an amalgamation project. See b(1) for details. * Alternative, shell-friendly command line buildspec and variable assignment syntax. For example: b test: foo/ bar/ b config.import.libhello = ../libhello/ See b(1) for details. * Automatic loading of directory buildfiles, implied directory buildfiles. Now instead of explicitly writing: d = foo/ bar/ ./: $d doc{README} include $d We can just write: ./: foo/ bar/ doc{README} And if our buildfile simply builds all the subdirectories: ./: */ Then it can be omitted altogether. * Support of the PATH-based search as a fallback import mechanism for exe{} targets. * Support for the 'latest' value in the cxx.std variable which can be used to request the latest C++ standard available in the compiler. * Ternary and logical operators support in eval contexts. * Initial support for build system functions. See build2/function*.?xx for early details. * Assert directive. The grammar is as follows: assert [] assert! [] The expression must evaluate to 'true' or 'false', just like in if-else. Version 0.4.0 * Support for Windows. The toolchain can now be built and used on Windows with either MSVC or MinGW GCC. With VC, the toolchain can be built with version 14 Update 2 or later and used with any version from 7.1. /MD and, for C++, /EHsc are default but are overridden if an explicit value is specified in the coptions variable. * Support for C compilation. There is now the 'c' module in addition to 'cxx' as well as 'cc', which stands for C-common. Mixed source (C and C++) building is also supported. * Integration with pkg-config. Note that build2 doesn't use pkg-config to actually locate the libraries (because this functionality of pkg-config is broken when it comes to cross-compilation). Rather, it searches for the library (in the directories extracted from the compiler) itself and then looks for the corresponding .pc file (normally in the pkgconfig/ subdirectory of where it found the library). It then calls pkg-config to extract any additional options that might be needed to use the library from this specific .pc file. * Initial support for library versioning. Currently, only platform-independent versions are supported. They get appended to the library name/soname. For example: lib{foo}: bin.lib.version = @-1.2 This will produce libfoo-1.2.so, libfoo-1.2.dll, etc. In the future the plan is to support platform-specific versions, for example: lib{foo}: bin.lib.version = linux@1.2.3 freebsd@1.2 windows@1.2 * Library dependency export support. In build2 a library dependency on another library is either an "interface" or "implementation". If it is an interface, then everyone who links this library should also be linking the interface dependency. A good example of an interface dependency is a library API that is called in an inline function. Interface dependencies of a library should be explicitly listed in the *.export.libs variable (where we can now list target names). The typical usage will be along these lines: import int_libs = libformat%lib{format} import int_libs += ... import imp_libs = libprint%lib{print} import imp_libs += ... lib{hello}: ... $imp_libs $int_libs lib{hello}: cxx.export.libs = $int_libs There is support for symbol exporting on Windows and build2 now also does all the right things when linking static vs shared libraries with regards to which library dependencies to link, which -rpath/-rpath-link options to pass, etc. * Support for the uninstall operation in addition to install. * Support for preserving subdirectories when installing. This is useful, for example, when installing headers: install.include = $install.include/foo/ install.include.subdirs = true The base for calculating the subdirectories is the scope where the subdirs value is set. * Support for installing as a different file name. Now the install variable is a path, not dir_path. If it is a directory (ends with a trailing slash), then the target is installed into this directory with the same name. Otherwise, the entire path is used as the installation destination. * Support for config.bin.{,lib,exe}.{prefix,suffix}. This replaces the bin.libprefix functionality. * Support for global config.install.{cmd,options,sudo,mode,dir_mode}. This way we can do: b install \ config.install.data_root=/opt/data \ config.install.exec_root=/opt/exec \ config.install.sudo=sudo * The new -V option is an alias for --verbose 3 (show all commands). * Support for specifying directories in config.dist.archives. For example, this command will create /tmp/foo-X.Y.Z.tar.xz: b foo/ config.dist.archives=/tmp/tar.xz * The cxx (and c) module is now project root-only. This means these modules can only be loaded in the project root scope (normally root.build). Also, the c.std and cxx.std values must now be set before loading the module to take effect. * The test, dist, install, and extension variables now have target visibility to prevent accidental "reuse" for other purposes. * An empty config.import.* value is now treated as an instruction to skip subproject search. Also, explicit config.import.* values now take precedence over the subproject search. * Search for subprojects is no longer recursive. In the future the plan is to allow specifying wildcard paths (* and **) in the subprojects variable. * Support out-qualified target syntax for setting target-specific variables on targets from src_base. For example: doc{INSTALL}@./: install = false * Only "effective escaping" (['"\$(]) is now performed for values on the command line. This makes for a more usable interface on Windows provided we use "sane" paths (no spaces, no (), etc). * The default variable override scope has been changed from "projects and subprojects" to "amalgamation". The "projects and subprojects" semantics resulted in counter-intuitive behavior. For example, in a project with tests/ as a subproject if one builds one of the tests directly with a non-global override (say C++ compiler), then the main project would be built without the overrides. In this light, overriding in the whole amalgamation seems like the right thing to do. The old behavior can still be obtained with explicit scope qualification, for example: b ./:foo=bar * The config.build format has been made more readable. Specifically, the order is now from the higher-level modules (e.g., c, cxx) to the lower-level (e.g., binutils) with imports coming first. The file now also includes an explicit version for incompatibility detected/migration in the future. * Support for <, >, <=, >= in the eval context. Now we can write: if ($build.version >= 40000) * Support for single line if-blocks. Now we can write: if true print true else print false Instead of having to do: if true { print true } else { print false } * Support for prepend/append in target type/pattern-specific variables. Semantically, these are similar to variable overrides and are essentially treated as "templates" that are applied on lookup to the "stem" value that is specific to the target type/name. For example: x = [string] a file{f*}: x =+ b sub/: { file{*}: x += c print $(file{foo}:x) # abc print $(file{bar}:x) # ac } * The obj*{} target type to exe/lib mapping has been redesigned. Specifically: - objso{} and libso{} target types have been renamed to objs{} and libs{} - obje{} has been added (so now we have obje{}, obja{}, and objs{}) - obje{} is now used for building exe{} - object file extensions now use "hierarchical extensions" that reflect the extension of the corresponding exe/lib target (instead of the -so suffix we used), specifically: obje{}: foo.o, (UNIX), foo.exe.o (MinGW), foo.exe.obj (MSVC) obja{}: foo.a.o (UNIX, MinGW), foo.lib.obj (MSVC) objs{}: foo.so.o (UNIX), foo.dylib.o (Darwin), foo.dll.o (MinGW), foo.dll.obj (MSVC) We now also have libi{} which is the Windows DLL import library. When used, it is the first ad hoc group member of libs{}. Version 0.3.0 * Support for High Fidelity Builds (HFB). The C++ compile and link rules now detect when the compiler, options, or input file set have changed and trigger the update of the target. Some examples of the events that would now trigger an automatic update are: * compiler change (e.g., g++ to clang++), upgrade, or reconfiguration * change of compile/link options (e.g., -O2 to -O3) * replacement of a source file (e.g., foo.cpp with foo.cxx) * removal of a file from a library/executable * New command line variable override semantics. A command line variable can be an override (=), prefix (=+), or suffix (+=), for example: b config.cxx=clang++ config.cxx.coptions+=-g config.cxx.poptions=+-I/tmp Prefixes/suffixes are applied at the outsets of values set in buildfiles, provided these values were set (in those buildfiles) using =+/+= and not an expansion, for example: b x=+P x+=S x = y print $x # P y S x =+ p x += s print $x # P p y s S But: x = A $x B print $x # A P p y s S B By default an override applies to all the projects mentioned in the buildspec as well as to their subprojects. We can restrict an override to not apply to subprojects by prefixing it with '%', for example: b %config.cxx=clang++ configure An override can also be made global (i.e., it applies to all projects, including the imported ones) by prefixing it with '!'. As an example, compare these two command lines: b config.cxx.coptions+=-g b '!config.cxx.coptions+=-g' In the first case only the current project and its subprojects will be recompiled with the debug information. In the second case, everything that the current project requires (e.g., imported libraries) will be rebuilt with the debug information. Finally, we can also specify the scope from which an override should apply. For example, we may only want to rebuild tests with the debug information: b tests/:config.cxx.coptions+=-g * Attribute support. Attributes are key or key=value pairs enclosed in [] and separated with spaces. They come before the entity they apply to. Currently we recognize attributes for variables and values. For variables we recognize the following keys as types: bool uint64 string path dir_path abs_dir_path name strings paths dir_paths names For example: [uint64] x = 01 print $x # 1 x += 1 print $x # 2 Note that variable types are global, which means you could type a variable that is used by another project for something completely different. As a result, typing of values (see below) is recommended over variables. If you do type a variable, make sure it has a namespace (typing of unqualified variables may become illegal). For values we recognize the same set of types plus 'null'. The value type is preserved in prepend/append (=+/+=) but not in assignment. For example: x = [uint64] 01 print $x # 1 x += 1 print $x # 2 x = [string] 01 print $x # 01 x += 1 print $x # 011 x = [null] print $x # [null] Value attributes can also be used in the evaluation contexts, for example: if ($x == [null]) if ([uint64] $x == [uint64] 0) * Support for scope/target-qualified variable expansion. For example: print $(dir/:x) print $(file{target}:x) print $(dir/file{target}:x) * Command line options, variables, and buildspec can now be specified in any order. This is especially useful if you want to re-run the previous command with -v or add a forgotten config variable: b test -v b configure config.cxx=clang++ * Support for the Intel C++ compiler on Linux. * Implement C++ compiler detection. Currently recognized compilers and their ids (in the [-] form): gcc GCC clang Vanilla Clang clang-apple Apple Clang (and the g++ "alias") icc Intel icpc msvc Microsoft cl.exe The compiler id, version, and other information is available via the following build system variables: cxx.id cxx.id.{type,variant} cxx.version cxx.version.{major,minor,patch,build} cxx.signature cxx.checksum cxx.target cxx.target.{cpu,vendor,system,version,class} * Implement ar/ranlib detection. The following information is available via the build system variables: bin.ar.signature bin.ar.checksum bin.ranlib.signature bin.ranlib.checksum * On update for install the C++ link rule no longer uses the -rpath mechanism for finding prerequisite libraries. * Set build.host, build.host.{cpu,vendor,system,version,class} build system variables to the host triplet. By default it is set to the compiler target build2 was built with but a more precise value can be obtained with the --config-guess option. * Set build.version, build.version.{major,minor,patch,release,string} build system variables to the build2 version. * Extracted header dependencies (-M*) are now cached in the auxiliary dependency (.d) files rather than being re-extracted on every run. This speeds up the up-to-date check significantly. * Revert back to only cleaning prerequisites if they are in the same project. Cleaning everything as long as it is in the same strong amalgamation had some undesirable side effects. For example, in bpkg, upgrading a package (which requires clean/reconfigure) led to all its prerequisites being cleaned as well and then rebuilt. That was surprising, to say the least. * Allow escaping in double-quoted strings. * Implement --buildfile option that can be used to specify the alternative file to read build information from. If '-' is specified, read from STDIN. * New scoping semantics. The src tree paths are no longer entered into the scope map. Instead, targets from the src tree now include their out tree directories (which are, in essence, their "configuration", with regards to variable lookup). The only user-visible result of this change is the extra '@/' suffix that is added when a target is printed, for example, as part of the compilation command lines. Version 0.2.0 * First public release.