[build2-announce] build2 toolchain 0.4.0 released

Boris Kolpackov boris at codesynthesis.com
Wed Sep 7 12:29:36 UTC 2016


We have released build2 toolchain 0.4.0. It includes a large number of new
features in the build system, package manager, and repository web interface.
Note also that this is still an alpha release that is more of a technology
preview rather than anything that is ready for production. It has been
tested on Windows, Linux, Mac OS, and FreeBSD with GCC, Clang (both vanilla
and Apple's), MinGW GCC, MSVC, and Intel icc.

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


Note that this release is backwards-incompatible with 0.3.0 and cannot be
upgraded to with the package manager. Furthermore, the config.build format
has changed as well so you will have to reconfigure any existing projects
you might have.

Download and build instructions:


Download directory:


SHA256 checksums:

75605cb77b53401393fc988c65b1f20717b14de43ae5dd6ad94b1e54d1f4b29c *build2-toolchain-0.4.0.tar.gz
ae894a37883ec877bcdf152efb8cbd03d98eb4ffb250728f2b29248d89b787a4 *build2-toolchain-0.4.0.tar.xz
ac653bed3d01197ccd548fd648f0a1290e45f9998187a14cd515db224dcc5d68 *build2-baseutils-0.4.0-i686-windows.zip
058d2eaccd18181f21e4f7da629e057d65d019cff1f35d743680d91fac61c962 *build2-baseutils-0.4.0-x86_64-windows.zip
a1a6869003b41591858cba55d3eed5b9e058a69a7d4f5385ccb1c11e7e1e053a *build2-mingw-0.4.0-i686-windows.tar.xz
e723fe54fb6fcbdbd88c2453ce6b750977ef568d71efc359c2fc49de1a7bc305 *build2-mingw-0.4.0-x86_64-windows.tar.xz

Note that the cppget.org repository that hosts the individual packages
is now signed. Its certificate details and the SHA256 fingerprint are:

CN=cppget.org/O=Code Synthesis/admin at cppget.org

NEWS file entries:

build2 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

  * 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

    lib{foo}: bin.lib.version = linux at 1.2.3 freebsd at 1.2 windows at 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

    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 \

  * 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
      print false

    Instead of having to do:

    if true
      print true
      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

      file{*}: x += c

      print $(file{foo}:x)  # abc
      print $(file{bar}:x)  # ac

  * The obj*{} target type to exe/lib mapping has been redesigned.


    - 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{}.

bpkg version 0.4.0

  * Support for repository signing and authentication.

    The rep-create command can now sign the repository with rep-fetch(fetch)
    and rep-info authenticating it. See the bpkg-repository-signing(1) help
    topic for details.

  * Support for system packages.

    Now a package can be "built" as available from the system rather than
    compiling it from source. To specify a system package the new sys: package
    scheme is used, for example:

    bpkg build sys:libsqlite3

    Currently, if no version is specified for a system package, then it is
    considered to be unknown but satisfying any dependency constraint (such a
    wildcard version is displayed as '*'). In the future bpkg will support
    querying system package managers (rpm, dpkg, pkg-config) for the installed

    See the pkg-build(build) man page for details.

  * Support for stub packages.

    A stub is a package without source code. It has the special upstream
    version 0 (with a possible revision, for example 0+1) and can only be
    built as a system package.

  * Support for build-time dependencies.

    Now a depends: value in the package manifest that starts with '*' is
    recognized as a built-time dependency.  Currently, build-time dependencies
    are treated in the same way as normal (run-time) ones except that the
    'build2' and 'bpkg' names are recognized as special. They can be used to
    specify a constraint (usually the required minimum version) on the build2
    build system and package manager, respectively. In the future, the
    semantics for build-time dependencies will be extended, for example, to
    verify that they can be executed on the build machine and/or to build them
    in a separate configuration in case of cross-compilation.

  * The pkg-build(build) command now offers to automatically update dependent
    packages that were reconfigured.

    It also supports the following new options:


     As well as the -K alias for --keep-prerequisite. See the command's man
     page for details.

  * The pkg-drop(drop) command now supports the following new options:


    See the command's man page for details.

  * The cfg-add command was renamed to rep-add (the add alias stays the same)
    and cfg-fetch to rep-fetch (the fetch alias stays the same).

  * The new -V option is an alias for --verbose 3 (show all commands).

brep version 0.4.0

  * Support for signed repositories.

    The repository certificate information (subject, fingerprint) and the
    certificate itself are now displayed on the repository about page.

  * Support for displaying stub packages, build-time dependencies.

  * All the brep prerequisites except the Apache2 headers are now available as
    build2 packages. This significantly simplifies building. See the INSTALL
    file for details.


More information about the announce mailing list