[build2] build2 0.12.0 released

Boris Kolpackov boris at codesynthesis.com
Wed Nov 20 12:36:41 UTC 2019

We have released build2 toolchain version 0.12.0. The main objective of this
release was support for build system modules and it took a while to tie up all
the loose ends in this area. As a result, this release has accumulated quite a
large number of other major new features across the toolchain.

A note on backwards compatibility: in this release the build system saw a
major reorganization (discussed below). As a result, this release cannot be
upgraded to from 0.11.0 and has to be installed from scratch.

The corresponding NEWS file entries are included below with a more detailed
discussion of the major new features available in the release notes:


In other news, we now have the Contributing section on our Community page:


As well as the Project Roadmap:


This release has been tested on Windows, Linux, Mac OS, and FreeBSD with
GCC, Clang (both vanilla and Apple's), MinGW GCC, and MSVC (14, 15, and
16). A big thank you to everyone who helped test the staged snapshots.

Note that all the install scripts and batch files now support the --local
option to skip building the final version from packages and instead build it
from the build2-toolchain archive directly. In particular, this can be used
for offline installation.

The following new build configurations have been added to the CI service:





For the complete list of available build configurations see:


Installation instructions:


Download directory:


SHA256 checksums:

  da35b527aac3427b449ca7525e97f81faba776ae7680179521963b90a21fba12 *build2-install-0.12.0.sh
  f3eedb06b13fc74d5cac762a6c73e43f232815724e816176bfed51862296ba77 *build2-install-clang-0.12.0.bat
  19bdf0b1b33e86cae11fb18cb0b03559bf3f0e0289dbb96af5bcdd325411398e *build2-install-msvc-0.12.0.bat
  2e20744621478fd2d96e29df70721587996dfa647a03def567b82b619788f46c *build2-install-mingw-0.12.0.bat

  a0ecf9930b873242a0164653411caca2cc5c095abda5ee7bda800f1b0f93e396 *build2-toolchain-0.12.0.tar.xz
  1de1e1740a5359295262b21209d0372e0958d7c6cd50863c9697b56aac65f10a *build2-toolchain-0.12.0.tar.gz

  b998d0278a532220a6af156db900209e294135658caf6813db42254e3dbfe475 *build2-baseutils-0.12.0-x86_64-windows.zip
  fd88a17f4dd498bc2d7958e141fcaca7e6d6b106d779a6a24cdb0160f91c8177 *build2-mingw-0.12.0-x86_64-windows.tar.xz

Repository certificate fingerprint for cppget.org:


NEWS file entries:

build2 version 0.12.0

  * Support for dynamically-buildable/loadable build system modules.

    See the libbuild2-hello sample module to get started:


  * Support for pattern matching (switch).

    For example:

    switch $cxx.target.class, $cxx.target.system
      case 'windows', 'mingw32'
	cxx.libs += -lrpcrt4

      case 'windows'
        cxx.libs += rpcrt4.lib

      case 'macos'
        cxx.libs += -framework CoreFoundation

    See the "Pattern Matching (switch)" section in the manual for details.

  * Support for default options files (aka tool config files).

    See the DEFAULT OPTIONS FILES section in b(1) for details.

  * Support for Clang targeting MSVC runtime on Windows.

    In particular, the build2 toolchain itself can now be built with Clang on
    Windows, including using LLD. See the "Clang Compiler Toolchain" section
    in the manual for details.

  * Support for automatic installation discovery for MSVC 15 (2017) and later.

    In particular, this allows building outside the Visual Studio development
    command prompts. See the "MSVC Compiler Toolchain" section in the manual
    for details.

  * Ability to specify "compiler mode" options as part of config.{c,cxx}.

    Such options are not overridden in buildfiles and are passed last (after
    cc.coptions and {c,cxx}.coptions) in the resulting command lines. Note
    that they are also cross-hinted between config.c and config.cxx. For

    $ b config.cxx="g++-9 -m32"  # implies config.c="gcc-9 -m32"


    $ b config.cxx="clang++ -stdlib=libc++" config.c=clang

  * Support for [config.]{cc,c,cxx}.aoptions (archive options).

    In particular, this can be used to suppress lib.exe warnings, for example:

    cc.aoptions += /IGNORE:4221

  * The cxx.std=latest value has been remapped from c++latest to c++17 for
    MSVC 16 (2019).

    See issue #34 for background:


  * Support for bracket expressions ([...]) in wildcard patterns.

    See the "Name Patterns" section in the manual for details.

  * Support for native shared library versioning on Linux.

    Now we can do:

    lib{foo}: bin.lib.version = linux at 1.2

    And end up with:

    libfoo.so.1    -> libfoo.so.1.2

    See issue #49 for background and details:


  * Changes to the Buildfile language functions:

    - $string.icasecmp(): new

    - $regex.replace_lines(): new

    - $regex.{match,search}(): now return NULL on no match with return_* flags

    - $filesystem.path_match(): renamed to $path.match()

    - $quote(): new

      This function can be useful if we want to pass a value on the command
      line, for example, in a testscript:

      $* config.cxx=$quote($recall($cxx.path) $cxx.mode, true)

    - $config.save(): new

      This is similar to the config.config.save variable functionality (see
      below) except that it can be called from within buildfiles and with the
      result saved in a variable, printed, etc.

      Note that this function can only be used during configure unless the
      config module creation was forced for other meta-operations with
      config.config.module=true in bootstrap.build.

  * Support for configuration exporting and importing.

    The new config.config.save variable specifies the alternative file to
    write the configuration to as part of the configure meta-operation. For

    $ b configure: proj/ config.config.save=proj-config.build

    The config.config.save value "applies" only to the projects on whose root
    scope it is specified or if it is a global override (the latter is a bit
    iffy but we allow it, for example, to dump everything to stdout). This
    means that in order to save a subproject's configuration we will have to
    use a scope-specific override (since the default will apply to the
    outermost amalgamation). For example:

    $ b configure: subproj/ subproj/config.config.save=.../subproj-config.build

    This is somewhat counter-intuitive but then it will be the amalgamation
    whose configuration we would normally want to export.

    The new config.config.load variable specifies additional configuration
    files to be loaded after the project's default config.build, if any. For

    $ b create: cfg/,cc config.config.load=.../my-config.build

    Similar to config.config.save, the config.config.load value "applies" only
    to the project on whose root scope it is specified or if it is a global
    override. This allows the use of the standard override "positioning"
    machinery (i.e., where the override applies) to decide where the extra
    configuration files are loaded. The resulting semantics is quite natural
    and consistent with command line variable overrides, for example:

    $ b   config.config.load=.../config.build  # outermost amalgamation
    $ b ./config.config.load=.../config.build  # this project
    $ b  !config.config.load=.../config.build  # every project

    Both config.config.load and config.config.save recognize the special `-`
    file name as an instruction to read/write from/to stdin/stdout,
    respectively. For example:

    $ b configure: src-prj/ config.config.save=- | \
      b configure: dst-prj/ config.config.load=-

    The config.config.load also recognizes the `~host` special configuration
    name. This is the "default host configuration" that corresponds to how the
    build system itself was built. For example:

    $ b create: tools/,cc config.config.load=~host

  * Attributes are now comma-separated with support for arbitrary values.


    x = [string null]


    x = [string, null]

  * The build system has been split into a library (libbuild2) a set of
    modules, and a driver.

    See the following mailing list post for details:


    As part of this change the following configuration macros (normally
    supplied via the -D preprocessor options) have been renamed from their old
    BUILD2_* versions to:


  * A notion of build context.

    All the non-const global state has been moved to class context and we can
    now have multiple independent builds at the same time. In particular, this
    functionality is used to update build system modules as part of another

  * New --silent options.

    Now in certain contexts (for example, while updating build system modules)
    the --quiet|-q verbosity level is ignored. We can specify --silent instead
    to run quietly in all contexts.

  * Support for the for_install prerequisite-specific variable.

    Setting this variable to true or false controls whether a prerequisite
    will be used by the link rule depending on whether the update is for
    install or not. Also reserve for_test for future use.

  * New config.config.persist variable.

    This variable is part of the initial support for customizable config.*
    variable persistence.

  * New bin.lib.load_suffix variable.

    Setting this variable triggers the creation of yet another symlink to the
    shared library that is meant to be used for dynamic loading. For example,
    we may want to embed the main program interface number into its plugins to
    make sure that we only load compatible versions.

  * New bin.lib.{version_pattern,load_suffix_pattern} variables.

    These variables allow specifying custom version and load suffix patterns
    that are used to automatically cleanup files corresponding to previous

  * Rename the config.cxx.importable_headers variable to

    The new name aligns better with the post-Cologne importable/translatable

  * The libu{} target group has been removed.

    The semantics provided by libu{} is rarely required and as a result has
    not yet been documented. However, if you are using it, the new way to
    achieve the same result is to use both libue{} and libul{} explicitly, for

    exe{foo}: libue{foo}
    lib{foo}: libul{foo}

    {libue libul}{foo}: cxx{*}

bdep version 0.12.0

  * Support for creating new projects with existing files.

    The bdep-new command now also recognizes and handles the following
    existing filesystem entries in the project root:

      .git      -- assume VCS is already initialized and is Git
      LICENSE   -- try to guess the manifest license from contents
      README.md -- try to extract the manifest summary line from contents

    Overall, the idea is to streamline the workflow where one creates a
    project on one of the hosting services (GitHub, GitLab, etc) and then
    initializes it with bdep-new.

    Also, to this effect, specifying the project name is now optional and if
    omitted, the current working directory (or --output-dir, if specified) is
    assumed to be the project name.

    An example of this streamlined workflow:

    $ # create project with LICENSE and README.md on a Git hosting service
    $ git clone .../libhello.git
    $ cd libhello
    $ bdep new -t lib

    Finally, with this change it now makes sense to have support for pre-
    creation hooks (--pre-hook) in addition to post-creation (--post-hook).

  * Support for default options files (aka tool config files).

    See the bdep-default-options-files(1) help topic for background and the
    DEFAULT OPTIONS FILES section in each command's man pages for specifics.

  * New bdep-new no-install project type sub-option.

    In particular, this should be useful when creating *-tests packages.

  * The C library projects created by bdep-new are now portable.

    Specifically, the use of fmemopen() was replaced with tmpfile().

  * The pre and post-creation hooks now make use of portable builtins.

    To instead use a system-provided program, prefix the name with `^`, for

    $ bdep new --post-hook "^cat --squeeze-blank .../.gitignore >>.gitignore"

    See bdep-new(1) for details.

  * Ability to specify <pkg-args> in the bdep-init command's -A and -C forms.

  * Ability to keep/update/remove the current tag in the bdep-release
    command's revision mode.

    Note also that previously the default was to update while now it is to

  * Ability to have multiple forwarded configurations.

    The new constraint is that such configurations should not have any common
    packages (a package's source directory cannot be forwarded to multiple

  * New bdep-submit --forward option.

    This option instructs bdep-submit to use each package's forwarded
    configuration in order to prepare the distributions. This helps with
    setups where there is no single configuration that has all the packages
    (such as a build system module project).

  * New bdep-init --no-sync option.

    This allows postponing initialization in the build configurations to a
    later explicit bdep-sync. One subtle difference with such an explicit sync
    is that it will be performed without having the project's database open,
    which can be important if the initialization triggers an implicit sync
    (via a hook) of a project that uses the same database (as is the case with
    build system module projects).

bpkg version 0.12.0

  * Ability to specify the full package version constraint in the pkg-build

    For example:

    $ bpkg build "bar < 2.0.0"

    See bpkg-pkg-build(1) for details.

  * Support for default options files (aka tool config files).

    See the bpkg-default-options-files(1) help topic for background and the
    DEFAULT OPTIONS FILES section in each command's man pages for specifics.

  * Support for tests, examples, and benchmarks as separate packages.

    See the "tests, examples, benchmarks" section in the manual for details.

brep version 0.12.0

  * Support for specifying explicit environment names in buildtabs.

  * Support for tests, examples, and benchmarks as separate packages.

  * The submit-git handler can now replace an existing package version

  * Significant speedup to the builds page loading.

  * Unbuilt configurations are now displayed on the package version details

  * Support for marking internal repositories as non-buildable.

More information about the users mailing list