[build2-announce] build2 toolchain 0.3.0 released

[Boris Kolpackov]

Hi,

We have released build2 toolchain 0.3.0. It includes a 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
Linux, Mac OS, and FreeBSD. There is still no Windows support.

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

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

You can upgrade from the previous release with the package manager. However,
this has to be done via the bpkg 0.2.1 bug-fix release. In particular, you
cannot go directly from bpkg 0.2.0 to 0.3.0. Below is the recommended
sequence of steps:

$ b --version                 # 0.2.0
$ bpkg --version              # 0.2.0
$ bpkg fetch
$ bpkg build bpkg/0.2.1
$ bpkg install bpkg
$ bpkg --version              # 0.2.1
$ bpkg build build2 bpkg
$ bpkg install build2 bpkg
$ b --version                 # 0.3.0
$ bpkg --version              # 0.3.0

Download instructions:

https://build2.org/download.xhtml

Download directory:

https://download.build2.org/0.3/

SHA256 checksums:

500ab9513d92970f6b29d11d69b875c6750e90a80d398eadf0195d00938c28d3 *bpkg-0.3.0.tar.gz
b7864de8f9aadeb476154825250495acade2c46c8c56fd4802eb373fc04df80b *brep-0.3.0.tar.gz
b901cd8324ea461bc1235c5a8f505c4f49e5f9d588150365ffa059b52b6bfc5a *build2-0.3.0.tar.gz
44b71c876a7342323fea9c6172d099861ce35d2ed208fdacf5f2c9de6aa745f8 *build2-toolchain-0.3.0.tar.gz
d3694e2c3351b0ff6acb02486f6bc96be7ce28489ee2a471e91cf40c7b60b44e *libbpkg-0.3.0.tar.gz
7eedd48673755229a06dc0310c3578221d104041d867f9334cd53df8296820ef *libbutl-0.3.0.tar.gz
56352cc007b0a9060222bcead99bfca72de1373ba8f9965a7cc036b2d00e6381 *libodb-2.5.0.a3.tar.gz
827f0477cc0e6a87604ce3ee90936d9c83fa8e8714895c2a27c252e4cbe9011e *libodb-pgsql-2.5.0.a3.tar.gz
79682522fce948a8c82978badb2db17914795f2bbef7b0f3a80daa0fa9719da6 *libodb-sqlite-2.5.0.a3-1.tar.gz
6e9f4a842fe96a6a27b203cc2d021433558534bc3989991593ebd0f4135b433f *libstudxml-1.1.0.a3.tar.gz

NEWS file entries:

build2 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 <type>[-<variant>] 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
    '@<out-dir>/' suffix that is added when a target is printed, for example,
    as part of the compilation command lines.


bpkg version 0.3.0

  * Command line options and arguments can now be specified in any order. This
    is especially useful if you want to re-run the previous command with -v:

    bpkg update libfoo -v

  * The pkg-build command now offers to drop prerequisite packages that are no
    longer necessary. This can happen if a package that is being upgraded or
    downgraded changes its prerequisite set. You can use the
    --keep-prerequisite option to suppress this behavior.

  * The pkg-build command now updates all packages at once (that is, with a
    single build system invocation) instead of sequentially one at a time.
    This should improve performance, especially once parallelism is supported.

  * The rep-create command now loads the description-file and changes-file
    files from the package archives and includes their contents inline into
    the 'packages' manifest file.


brep version 0.3.0

  * Multiple instances of the brep module can now be configured on a single
    Apache2 server. The configuration can be specified at the Apache2 root,
    VistualHost, and Location levels.

  * Support for custom web page logo and menu entries. See comments in the
    etc/brep-module.conf file for details.

  * Use serializable transaction isolation, handle recoverable database errors
    (deadlock, loss of connection, etc).

  * Ability to specify the maximum number of concurrent database connections
    per web server process. See comments in the etc/brep-module.conf file for
    details.

  * Ability to specify the maximum number of times to retry database
    transactions. See comments in the etc/brep-module.conf file for details.

  * Display SHA256 package checksum on the package version details pages.

  * Add instructions to the INSTALL file on how to run the database loader via
    cron rather than systemd timers.

  * Add instructions to the INSTALL file on how to enable Apache2 compression
    for the brep output.

  * Add support for comments in the repository manifest email values.

  * Remove a DROP FUNCTION statement that caused an error on older PostgreSQL
    versions.

  * On startup log brep module version to Apache2 log.

  * The module implementation has been moved from brep/ to mod/ (only affects
    INSTALL-DEV setup).


Enjoy,
	Boris