[build2] build2 0.13.0 released

Boris Kolpackov boris at codesynthesis.com
Mon Jul 20 14:14:31 UTC 2020


We have released build2 toolchain version 0.13.0. The main focus of this
release is build system support for project-specific configurations and
ad hoc recipes. Another notable new feature is support for the creation
of alternative (e.g., with include/src split) source code layouts by the
bdep-new command. We have also switched to the SPDX License Expression
as the default license name scheme (old names in existing packages will
still work).

A note on backwards compatibility: this release cannot be upgraded to from
0.12.0 and has to be installed from scratch. Additionally, on UNIX-like
operating systems the installation script now installs the toolchain
libraries into a private subdirectory of lib/. This means that when
installed into a shared location such as /usr/local/, the toolchain
implementation details can no longer clash with anything that is already
installed or might be installed in the future into the same location by
the user.

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

  https://build2.org/release/0.13.0.xhtml

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 release candidate.

There is also now:
  - Experimental support for NetBSD.
  - Gentoo ebuild file: https://packages.gentoo.org/packages/dev-util/build2

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

  linux_debian_9-gcc_8.4
  linux_debian_10-gcc_9.3
  linux_debian_10-gcc_10.1
  linux_debian_10-clang_10.0[_libc++]

  macos_10.15-clang_11.0                      (Xcode 11.5 Clang 11.0.3)
  macos_10.15-gcc_9.3_homebrew

  windows_10-msvc_16.4
  windows_10-msvc_16.5
  windows_10-msvc_16.6
  windows_10-clang_10.0_llvm_msvc_16.6[_lld]
  windows_10-gcc_9.2_mingw_w64

In addition, there are now optimized and static optimized builds for the
latest version of every configuration. All in all, there are now 57 build
configurations, up from 42 in the previous release. For the complete list,
see:

  https://ci.cppget.org/?build-configs

Installation instructions:

  https://build2.org/install.xhtml

Download directory:

  https://download.build2.org/0.13.0/

SHA256 checksums:

aeec2ac0e7080341159bbbc95d8264521ddf82bda01c5c253d63cae5b4558b15 *build2-install-0.13.0.sh
bb20552ef26862ee9101c9e5f1677ddae911798bafc259b1ef06f64ba29ab163 *build2-install-msvc-0.13.0.bat
a8c08441c82b9601e61634933fa1bfe1ef08f0d4e22e51b34d50a33ad81f0163 *build2-install-clang-0.13.0.bat
60f36c7f5135676d0772dd67ccfac012b8bcb9e9177c9305a889fd54782b6870 *build2-install-mingw-0.13.0.bat

bafabcab4d5efdc489af59755a3ba7ce90834b479125cf21c34828857cc91506 *build2-toolchain-0.13.0.tar.xz
4be9fdd0c9511bd9ecf8399c4bc2eac46bd01e637e86ad0b76d7db482f4e5b11 *build2-toolchain-0.13.0.tar.gz

4382174132e1dc7ca79d7ab2d1406d14afbfc927b9814fe7e7285781eabc3022 *build2-baseutils-0.13.0-x86_64-windows.zip
00345f8e0ac5e93c9e2bee8cd6127fc922528a99ed4a543d7baa28a3a60b13e6 *build2-mingw-0.13.0-x86_64-windows.tar.xz

Repository certificate fingerprint for cppget.org:

  86:BA:D4:DE:2C:87:1A:EE:38:C7:F1:64:7F:65:77:02:15:79:F3:C4:83:C0:AB:5A:EA:F4:F7:8C:1D:63:30:C6

NEWS file entries:

build2 version 0.13.0

  * Support for project-specific configuration.

    A project can now use the config directive to define config.<project>.*
    variables, similar to the build system core and modules. For example:

    config [bool]   config.libhello.fancy    ?= false
    config [string] config.libhello.greeting ?= 'Hello'

    These variables can then be used in buildfiles and/or propagated to the
    source code using the command line, .in file substitution, etc. For
    example:

    if $config.libhello.fancy
      cxx.poptions += -DLIBHELLO_FANCY

    cxx.poptions += "-DLIBHELLO_GREETING=\"$config.libhello.greeting\""

    See the "Project Configuration" chapter in the manual for details.

  * Support for ad hoc recipes.

    With ad hoc recipes it is now possible to provide custom implementations
    of operations (update, test, etc) for certain targets. For example, this
    is how we can pick a config header based on the platform:

    hxx{config}: hxx{config-linux}: include = ($cxx.target.class == 'linux')
    hxx{config}: hxx{config-win32}: include = ($cxx.target.class == 'windows')
    hxx{config}: hxx{config-macos}: include = ($cxx.target.class == 'macos')
    hxx{config}:
    {{
      cp $path($<) $path($>)
    }}

    Another, more elaborate example that shows how to embed binary data into
    the source code with the help of the xxd(1) utility:

    import! xxd = xxd%exe{xxd}

    <{hxx cxx}{foo}>: file{foo.bin} $xxd
    {{
      diag xxd ($<[0])

      i = $path($<[0]) # Input.
      h = $path($>[0]) # Output header.
      s = $path($>[1]) # Output source.
      n = $name($<[0]) # Array name.

      # Get the position of the last byte (in hex).
      #
      $xxd -s -1 -l 1 $i | sed -n -e 's/^([0-9]+):.*$/\1/p' - | set pos

      if ($empty($pos))
        exit "unable to extract input size from xxd output"
      end

      # Write header and source.
      #
      echo "#pragma once"                         >$h
      echo "extern const char $n[0x$pos + 1];"   >>$h
      echo "extern const char $n[0x$pos + 1]= {"  >$s
      $xxd -i <$i                                >>$s
      echo '};'                                  >>$s
    }}

    Note that in both examples, the utilities (cp, echo, and sed) are builtins
    which means these recipes are portable. See the Testscript manual for the
    list of available builtins.

    Ad hoc recipes can also be used to customize a part of the update chain
    otherwise handled by rules. For example, in embedded systems development
    it is often required to perform a custom link step:

    obje{foo}: cxx{foo}
    obje{bar}: cxx{bar}

    <exe{test} file{test.map}>: obje{foo bar}
    {{
      diag ld ($>[0])
      $cxx.path $cc.loptions $cxx.loptions $cxx.mode -o $path($>[0]) \
        "-Wl,-Map=$path($>[1])" $path($<) $cxx.libs $cc.libs
    }}

    While the above examples are all for the update operation, ad hoc recipes
    can be used for other operations, such as test. For example:

    exe{hello}: cxx{hello}
    % test
    {{
      diag test $>
      $> 'World' >>>?'Hello, World!'
    }}

    The above recipes are written in a shell-like language called Buildscript
    that has similar semantics to Testscript tests. Another language that can
    be used to write recipes is C++. For example:

    ./:
    {{ c++ 1

      recipe
      apply (action, target& t) const override
      {
        text (recipe_loc) << "Hello, " << t;
        return noop_recipe;
      }
    }}

    Note that in this release support for ad hoc recipes is at the "technology
    preview" stage. In particular, there is no documentation and there might
    be some rough edges.

  * Support for project-local importation.

    An import without a project name is now treated as importation from the
    same project. For example, given the libhello project that exports the
    lib{hello} target, a buildfile for an executable in the same project
    instead of doing something like this:

    include ../libhello/
    exe{hello}: ../libhello/lib{hello}

    Can now do:

    import lib = lib{hello}
    exe{hello}: $lib

    Note that the target in project-local importation must still be exported
    in the project's export stub. In other words, project-local importation
    goes through the same mechanism as normal import.

    See the "Target Importation" section in the manual for details.

  * Support for ad hoc importation and "glue buildfiles".

    If the target being imported has no project name and is either absolute or
    is a relative directory, then this is treated as ad hoc importation.
    Semantically it is similar to normal importation but with the location of
    the project being imported hard-coded into the buildfile.

    In particular, this type of import can be used to create a special "glue
    buildfile" that "pulls" together several projects, usually for convenience
    of development. One typical case that calls for such a glue buildfile is a
    multi-package project. To be able to invoke the build system directly in
    the project root, we can add a glue buildfile that imports and builds all
    the packages:

    import pkgs = */
    ./: $pkgs

    See the "Target Importation" section in the manual for details.

  * Support for value subscripts.

    A value subscript is only recognized in evaluation contexts (due to
    ambiguity with wildcard patterns; consider: $x[123].txt) and should be
    unseparated from the previous token. For example:

    x = ($y[1])
    x = (($f ? $y : $z)[1])
    x = ($identity($y)[$z])

  * New legal{} target type and config.install.legal variable.

    This allows separation of legal files (LICENSE, AUTHORS, etc) from other
    documentation. For example:

    ./: ... doc{README} legal{LICENSE}

    $ b install ... config.install.legal='share/licenses/<project>/'

  * Support for <var>-substitutions in config.install.* values.

    The currently recognized variable names are <project> and <private> which
    are replaced with the project name and private subdirectory, respectively.
    This can be used along these lines:

    $ b config.install.libexec='exec_root/lib/<project>/' install

    The private installation subdirectory can be used to hide the
    implementation details of a project. This is primarily useful when
    installing an executable that depends on a bunch of libraries into a
    shared location, such as /usr/local/. For example:

    $ b config.install.private=foo install

    See the "Install Module" chapter in the manual for details.

  * New $regex.find_{match,search}() functions that operate on lists.

  * The $process.run*() functions now recognize a number of portable builtins.

    Refer to the Testscript manual for the list and details.

  * New $defined(<variable>) and $visibility(<variable>) functions.

  * New $target.process_path() function for exe{} targets analogous to
    $target.path().

  * New $bin.link_member() function.

    Given a linker output target type (exe, lib[as], or libu[eas]) this
    function returns the target type of the lib{} group member (liba or libs)
    that will be picked when linking a lib{} group to this target type.

  * New scripting builtins: date, env.

    Refer to the Testscript manual for details.

  * New variable block applicability semantics in dependency chains.

    Previously the block used to apply to the set of prerequisites before the
    last colon. This turned out to be counterintuitive and not very useful
    since prerequisite-specific variables are less common than target-
    specific ones.

    The new rule is as follows: if the chain ends with a colon, then the block
    applies to the last set of prerequisites. Otherwise, it applies to the
    last set of targets. For example:

    ./: exe{test}: cxx{main}
    {
      test = true        # Applies to the exe{test} target.
    }

    ./: exe{test}: libue{test}:
    {
      bin.whole = false  # Applies to the libue{test} prerequisite.
    }

  * Test and install modules are now implicitly loaded for simple projects.

    While these can be useful on their own, this also makes the test and
    install operations available in simple projects, which is handy for "glue
    buildfiles" that "pull" (using ad hoc import) a bunch of other projects
    together.

  * The translated {c,cxx}.std options are now folded into the compiler mode
    options ({c,cxx}.mode).

    This makes them accessible from ad hoc recipes. The original mode/path are
    available in {c,cxx}.config.mode/path.

  * Generation of a common pkg-config .pc file in addition to static/shared-
    specific.

    The common .pc file is produced by ignoring any static/shared-specific
    poptions and splitting loptions/libs into Libs/Libs.private.

    It is "best effort", in a sense that it's not guaranteed to be sufficient
    in all cases, but it will probably cover the majority of cases, even on
    Windows, thanks to automatic dllimport'ing of functions.

  * The ~host configuration now only contains the cc and bin modules
    configuration.

    There is also the new ~build2 configuration that contains everything
    (except config.dist.*) and is meant to be used for build system modules.

  * Reworked tool importation support.

    Specifically, now config.<tool> (like config.cli) is handled by the import
    machinery (it is a shorter alias for config.import.<tool>.<tool>.exe that
    we already had).

    This also adds support for uniform tool metadata extraction that is
    handled by the import machinery. As a result, a tool that follows the
    "build2 way" can be imported with metadata by the buildfile and/or
    corresponding module without any tool-specific code or brittleness
    associated with parsing --version or similar outputs. See the cli
    tool/module for an example of how this all fits together.

    Finally, two new flavors of the import directive are now supported:
    import! triggers immediate importation skipping any rule-specific logic
    while import? is optional import (analogous to using?). Note that optional
    import is always immediate. There is also the import-specific metadata
    attribute which can be specified for these two import flavors in order to
    trigger metadata importation. For example:

    import? [metadata] cli = cli%exe{cli}

    if ($cli != [null])
      info "cli version $($cli:cli.version)"

  * Backtick (`) and bit-or (|) are reserved in eval context for future use.

    Specifically, they are reserved for planned support of arithmetic eval
    contexts and evaluation pipelines, respectively.


bpkg version 0.13.0

  * The SPDX License Expression is now the default scheme for the 'license'
    package manifest value.

    See the "license" section in the manual for details.

  * New --pkg-proxy common option.

    This option specifies the proxy server to use when fetching package
    manifests and archives from remote pkg repositories. See the option
    documentation in bpkg-common(1) for details.

  * External test packages can now have their own build constraints.


bdep version 0.13.0

  * The SPDX License Expression in now the default scheme in the bdep-new
    --type|-t,license sub-option.

    Auto-detected licenses now also result in the SPDX License ID in the
    'license' package manifest value.

  * New source layout customization mechanisms in bdep-new.

    In particular, the split include/src layout is now supported out of the
    box:

    $ bdep new -l c++ -t lib,split libhello

    See the SOURCE LAYOUT section in bdep-new(1) for details and a large
    number of examples.

  * The bdep-new command in the --package mode now creates the "glue
    buildfile" for the project.

  * The bdep-new command now generates the .gitattributes file with sensible
    defaults.

  * The bdep-new --subdirectory mode option has been renamed to --source.

    The corresponding default options file has also been renamed to
    bdep-new-source.options.

  * The bdep-new binless sub-option has been moved from --lang|-l to --type|t.


brep version 0.13.0

  * Support for the alternative package rebuild timeout.

    The alternative rebuild timeout can be used to "pull" the rebuild window
    to the specified time of day, for example, to optimize load and/or power
    consumption of the build infrastructure (off-work hours, solar, off-peak
    electricity tariffs, etc).

  * New brep-monitor utility for monitoring for and reporting on brep state
    issues. Currently it only reports build delays. See brep-monitor(1) for
    details.

  * Support for test-exclude task manifest value.


bbot version 0.13.0

  * Build logs are now UTF-8-sanitized by the worker.

  * Support for test-exclude task manifest value.

  * Bootstrap timeout has been increased from 30 to 60 minutes.



More information about the users mailing list