Version 0.18.0

  * Ability to override imported installed library path/name.

    Specifically, the config.import.<proj>.<name>.{lib,liba,libs} variables
    can be used to specify alternative location and/or name for an installed
    library. This, in particular, can be useful when trying to use a library
    installed with a prefix or suffix. For example, if the library was
    installed with the `D` suffix:

    config.import.libfoo.foo.lib=fooD

    For the config.*.lib variable, the valid values are a simple path (which
    is used as a library name base), an absolute directory (which is used as a
    library location), or both. For example:

    config.import.libfoo.foo.lib=/tmp/lib/
    config.import.libfoo.foo.lib=/tmp/lib/fooD

    For the config.*.{liba,libs} variables, the valid values are a simple name
    (which is used as a library name), or an absolute path (which is used as a
    library location and name). For example:

    config.import.libfoo.foo.libs=libfooD.so
    config.import.libfoo.foo.liba=/tmp/lib/libfooD.a

    Note that on Windows, the shared library name/path should refer to the
    import library, not the DLL.

Version 0.17.0

  * C++20 modules support improvements:

    - Named modules support in Clang, including automatic building of the
      `std` and `std.compat` standard library modules from libc++ with Clang
      18 or later.

    - Named modules support in MSVC, including automatic building of the `std`
      and `std.compat` standard library modules.

      Note: if combining the standard library modules importation with the
      standard library headers inclusion, MSVC 17.10 or later is recommended.

    - Modules support can now be enabled for any std.cxx value greater or
      equal 20 (including `latest`).

    - The "C++ Modules Support" section in the manual has been updated to
      match the current state of the implementation.

  * The `latest` and `experimental` cxx.std values are now mapped to C++26
    from GCC 14 and Clang 18.

  * The 23 and 2x c.std values are now mapped to /std:clatest starting from
    MSVC 17.9. In particular, this option enables C23 typeof support.

  * /Zc:preprocessor is now added for the `experimental` cxx.std value from
    MSVC 17.9.

  * New string_set buildfile value type.

    This exposes the std::set<std::string> type to buildfiles.

    New functions:

      $size(<string-set>)

    Subscript returns true if the value is present and false otherwise (so
    it is mapped to std::set::contains()). For example:

    set = [string_set] a b c

    if ($set[b])
      ...

    Note that append (+=) and prepend (=+) have the same semantics
    (std::set::insert()). For example:

    set = [string_set] a b
    set += c b              # a b c
    set =+ d b              # a b c d

    Example of iteration:

    set = [string_set] a b c
    for k: $set
      ...

  * New string_map buildfile value type.

    This exposes the std::map<std::string,std::string> type to buildfiles.

    New functions:

      $size(<string-map>)
      $keys(<string-map>)

    Subscript can be used to look up a value by key. The result is [null] if
    there is no value associated with the specified key. For example:

    map = [string_map] a@1 b@2 c@3

    b = ($map[b])  # 2

    if ($map[z] == [null])
      ...

    Note that append (+=) is overriding (like std::map::insert_or_assign())
    while prepend (=+) is not (like std::map::insert()). In a sense, whatever
    appears last (from left to right) is kept, which is consistent with what
    we expect to happen when specifying the same key repeatedly in a literal
    representation. For example:

    map = [string_map] a@0 b@2 a@1  # a@1 b@2
    map += b@0 c@3                  # a@1 b@0 c@3
    map =+ b@1 d@4                  # a@1 b@0 c@3 d@4

    Example of iteration:

    map = [string_map] a@1 b@2 c@3
    for p: $map
    {
      k = $first($p)
      v = $second($p)
    }

    While the subscript is mapped to key lookup only, index-based access can
    be implemented (with a bit of overhead) using the $keys() function:

    map = [string_map] a@1 b@2 c@3
    keys = $keys($m)
    for i: $integer_sequence(0, $size($keys))
    {
      k = ($keys[$i])
      v = ($map[$k])
    }

  * New JSON buildfile value types.

    New types:

      json
      json_array
      json_object

    New functions:

      $json.value_type(<json>)
      $json.value_size(<json>)
      $json.member_{name,value}(<json-member>)
      $json.object_names(<json-object>)
      $json.array_size(<json-array>)
      $json.array_find(<json-array>, <json>)
      $json.array_find_index(<json-array>, <json>)
      $json.load(<path>)
      $json.parse(<text>)
      $json.serialize(<json>[, <indentation>])

    See "JSON Functions" in the manual for details.

    For example, to load a JSON value from a file:

    j = $json.load($src_base/board.json)

    Or to construct it in a buildfile:

    j = [json] one@1 two@([json] 2 3 4) three@([json] x@1 y@-1)

    This can also be done incrementally with append/prepend:

    j = [json_object]
    j += one@1
    j += two@([json] 2 3 4)
    j += three@([json] x@1 y@-1)

    Instead of using this JSON-like syntax, one can also specify valid JSON
    input text:

    j = [json] '{"one":1, "two":[2, 3, 4], "three":{"x":1, "y":-1}'

    Besides the above set of functions, other handy ways to access components
    in a JSON value are iteration and subscript. For example:

    for m: $j
      print $member_name($m) $member_value($m)

    print ($j[three])

    A subscript can be nested:

    print ($j[two][1])
    print ($j[three][x])

    While a JSON value can be printed directly like any other value, the
    representation will not be pretty-printed. As a result, for complex
    JSON values, printing a serialized representation might be a more
    readable option:

    info $serialize($j)

  * New json_map and json_set buildfile value types.

    These expose the std::map<json_value,json_value> and std::set<json_value>
    types to buildfiles.

    New functions:

      $size(<json-set>)
      $size(<json-map>)
      $keys(<json-map>)

    Note that the $keys() function returns the list of map key as a json
    array.

    For example:

    m = [json_map] 2@([json] a@1 b@2) 1@([json] 1 2)
    s = [json_set] ([json] x@1 y@2) ([json] a@1 b@2)

    print ($m[2][b])              # 2
    print ($s[([json] y@2 x@1)])  # true

  * New $first() and $second() functions which return the first and second
    halves of a pair, respectively.

  * New string functions:

    $string.contains()
    $string.starts_with()
    $string.ends_with()
    $string.replace()

    See "String Functions" in the manual for details.

  * New path functions:

    $path.absolute()
    $path.simple()
    $path.sub_path()
    $path.super_path()
    $path.complete()
    $path.try_normalize()
    $path.try_actualize()

    See "Path Functions" in the manual for details.

  * New filesystem functions:

    $filesystem.file_exists()
    $filesystem.directory_exists()

    See "Filesystem Functions" in the manual for details.

  * Runtime/buildtime distinction when installing libraries.

    Specifically, now, if a library is installed solely as a prerequisite of
    an executable (potentially recursively), then only its runtime files are
    installed omitting everything buildtime-related (static/import libraries,
    non-versioned symlinks for shared libraries, pkg-config files, headers,
    etc). If you are familiar with the runtime and -dev/-devel package splits
    for libraries in Debian/Fedora, this is the analogous semantics.

  * Support for extracting C and C++ predefined macros (predefs).

    Specifically, the c and cxx modules now provide the c.predefs and
    cxx.predefs submodules which can be loaded in order to register a rule
    that generates a C or C++ header with the predefined compiler macros,
    respectively. For details, refer to "C Compiler Predefined Macro
    Extraction" and "C++ Compiler Predefined Macro Extraction" in the manual.

  * Ability to serialize compilation/linking in C/C++ rules.

    Specifically, both the C/C++ compile and link rules now recognize the
    cc.serialize boolean variable which instructs them to compile/link
    serially with regards to any other recipe.

    This is primarily useful when compiling large translation units or linking
    large binaries that require so much memory that doing that in parallel
    with other compilation/linking jobs is likely to summon the OOM killer.
    For example:

    obj{memory-hog}: cc.serialize = true

  * Ability to specify compiler mode options in a buildfile.

    Now the configured mode options are appended to buildfile-specified (which
    must be specified before loading the guess module).

    In particular, this ability to specify the compiler mode in a buildfile is
    useful in embedded development where the project may need to hardcode
    options like -target, -nostdinc, etc. For example:

    cxx.std = 20
    cxx.mode = -target riscv32-unknown-unknown -nostdinc
    using cxx

  * New ~host-no-warnings and ~build2-no-warnings special configurations.

    These are parallel to ~host and ~build2 but with suppressed C/C++ compiler
    warnings.

    Note also that the C++ ad hoc recipes are now by default built in
    ~build2-no-warnings instead of ~build2 unless the project is configured
    for development with config.<project>.develop=true.

  * New {bin,c,cxx}.types submodules that only register target types.

    This is primarily useful when providing custom C/C++ compilation/linking
    rules.

  * New -s|--timeout-success option in the `env` script builtin.

    The semantics is equivalent to the --success option in the `timeout`
    builtin.

  * Ability to specify alternative sysroot for pkg-config files.

    Specifically, the new config.cc.pkgconfig.sysroot variable provides
    roughly equivalent functionality to PKG_CONFIG_SYSROOT_DIR in
    pkg-config. For details and limitations, see "Rewriting Installed
    Libraries System Root (sysroot)" in the manual for details.

  * Ability to alias a target type from another project.

    The syntax is:

    define <type> = <proj-scope>/<type>

    For example:

    sdk_proj = ... # Root directory of the SDK.
    define ldscript = $sdk_proj/ldscript


    Additionally, unknown target types of imported targets are now aliased
    automatically.

  * New no_default_target attribute for source, buildfile import directives.

    This attribute can be used to disable the default target semantics for the
    sources/imported buildfile.

  * Allow imported buildfiles to use config.* variables from own projects
    (that is, the project from which the buildfile is imported).

  * The fsdir{} targets are now usable in ad hoc recipes.

    In particular, they can now be used to represent directory symlinks. For
    example:

    exe{hello}: ... fsdir{assets}

    fsdir{assets}:
    % update
    {{
      ln -s $src_base/assets $out_base/assets
    }}
    % clean
    {{
      rm $out_base/assets
    }}

    Likewise, file{} targets can now be used to represent file symlinks
    created in ad hoc recipes.

  * Ability to specify ad hoc recipes in separate files.

    This can now be achieved with the new `recipe` directive:

    recipe <language> <file>

    Note that similar to the use of if-else and switch directives with recipes,
    this directive requires explicit % recipe header. For example, instead of:

    file{foo.output}:
    {{
       echo 'hello' >$path($>)
    }}

    We can now write:

    file{foo.output}:
    %
    recipe buildscript hello.buildscript

    With hello.buildscript containing:

    echo 'hello' >$path($>)

    Similarly, for C++ recipes (this time for a pattern rule), instead of:

    [rule_name=hello] file{~'/(.+)\.output/'}:
    % update clean
    {{ c++ 1 --

    --

    ...

    }}

    We can now write:

    [rule_name=hello] file{~'/(.+)\.output/'}:
    % update clean
    recipe c++ hello.cxx

    With hello.cxx containing:

    // c++ 1 --

    --

    ...

    Relative <file> paths are resolved using the buildfile directory that
    contains the `recipe` directive as a base.

    Note also that this mechanism can be used in exported buildfiles with
    recipe files placed into build/export/ together with buildfiles.

Version 0.16.0

  * Support for Objective-C/C++ compilation.

    Specifically, the c and cxx modules now provide the c.objc and cxx.objcxx
    submodules which can be loaded in order to register the m{}/mm{} target
    types and enable Objective-C/C++ compilation in the c and cxx compile
    rules. Note that c.objc and cxx.objcxx must be loaded after the c and cxx
    modules, respectively, and while the m{}/mm{} target types are registered
    unconditionally, compilation is only enabled if the C/C++ compiler
    supports Objective-C/C++ for this target platform. Typical usage:

    # root.build
    #
    using cxx
    using cxx.objcxx

    # buildfile
    #
    lib{hello}: {hxx cxx}{*}
    lib{hello}: mm{*}: include = ($cxx.target.class == 'macos')

    Note also that while there is support for linking Objective-C/C++
    executables and libraries, this is done using the C/C++ compiler driver
    and no attempt to automatically link any necessary Objective-C runtime
    (such as -lobjc) is made. For details, refer to "Objective-C Compilation"
    and "Objective-C++ Compilation" in the manual.

  * Support for Assembler with C Preprocessor (.S) compilation.

    Specifically, the c module now provides the c.as-cpp submodule which can
    be loaded in order to register the S{} target type and enable Assembler
    with C Preprocessor compilation in the c compile rule. For details, refer
    to "Assembler with C Preprocessor Compilation" in the manual.

  * Support for buildfile importation.

    A project can now export buildfiles that can then be imported by other
    projects. This mechanism is primarily useful for exporting target type
    definitions and ad hoc rules.

    Specifically, a project can now place *.build files into its build/export/
    subdirectory (or *.build2 and build2/export/ in the alternative naming
    scheme). Such files can then be imported by other projects as buildfile{}
    targets. For example:

    import thrift%buildfile{thrift-cxx}

    While for other target types the semantics of import is to load the
    project's export stub and return the exported target, for buildfile{} the
    semantics is to source the imported buildfile at the point of importation.

    Note that care must be taken when authoring exported buildfiles since they
    will be sourced by other projects in unpredictable circumstances. In
    particular, the import directive by default does not prevent sourcing the
    same buildfile multiple times (neither in the same project nor in the same
    scope). As a result, if certain parts must only be sourced once per
    project (such as target type definitions), then they must be factored into
    a separate buildfile (in build/export/) that is imported by the "main"
    exported buildfile with the `once` attribute. For example, the above
    thrift-cxx.build may contain:

    import [once] thrift%buildfile{thrift-cxx-target-type}

    See also "install Module" in the manual for details on the exported
    buildfile installation.

  * Support for defining explicit (as opposed to ad hoc) target groups.

    A user-defined explicit target group must be derived from the group base
    target type. If desired, it can be marked as "see-through", meaning that
    when it is listed as a prerequisite of a target, the matching rule will
    "see" its members, rather than the group itself. For example:

    define [see_through] thrift_cxx: group

    define thrift: file
    thrift{*}: extension = thrift

    exe{hello}:       cxx{hello} thrift_cxx{data}
    thrift_cxx{data}: thrift{data}

    Explicit group members can be specified statically, injected by an ad hoc
    rule, or extracted dynamically by the depdb-dyndep builtin (see the next
    NEWS item). For example:

    thrift_cxx{data}<{hxx cxx}{data_constants}>: thrift{data}        # Static.

    thrift_cxx{~'/(.+)/'}<{hxx cxx}{^'/\1_types/'}>: thrift{~'/\1/'} # Inject.
    {{
       depdb dyndep --dyn-target ...                                 # Dynamic.
    }}

  * Support for dynamic target extraction in addition to prerequisites.

    This functionality is enabled with the depdb-dyndep --dyn-target option.
    If the recipe target is an explicit group (see the previous NEWS item),
    then the dynamically extracted targets are added as its members.
    Otherwise, the listed targets are added as ad hoc group members. In both
    cases the dynamically extracted target is ignored if it is already
    specified as a static member or injected by a rule. Note that this
    functionality is not available in the --byproduct mode. See the
    depdb-dyndep builtin options description for details.

  * New `lines` depdb-dyndep dependency format in addition to `make`.

    The `lines` format lists targets and/or prerequisites one per line. See
    the depdb-dyndep builtin options description for details.

  * Low verbosity diagnostics rework.

    The low verbosity (level 1) rule diagnostics format has been adjusted to
    include the output target where appropriate. The implementation has also
    been redesigned to go through the uniform print_diag() API, including for
    the `diag` pseudo-builtin in ad hoc recipes.

    Specifically, the `diag` builtin now expects its arguments to be in one of
    the following two forms (which correspond to the two print_diag() forms):

    diag <prog> <l-target> <comb> <r-target>...
    diag <prog> <r-target>...

    If the `diag` builtin is not specified, the default diagnostics is now
    equivalent to:

    For update:

    diag <prog> ($<[0]) -> $>

    And for other operations:

    diag <prog> $>

    For details, see the print_diag() API description in diagnostics.hxx. See
    also GitHub issue #40 for additional background/details.

  * Buffering of diagnostics from child processes.

    By default, unless running serially or --no-diag-buffer is specified,
    diagnostics issued by child processes (compilers, etc) is buffered and
    printed all at once after each child exits in order to prevent
    interleaving. See also the new --[no-]diag-color options.

  * New $path.posix_string() and $path.posix_representation() functions.

    These functions are similar to $path.string() and $path.representation()
    except that they always return the string/representation of a path in the
    POSIX notation, that is, using forward slashes.

  * New $regex.filter[_out]_{match,search}(<vals>, <pat>) functions.

    The match versions return elements of a list that match (filter) or do not
    match (filter_out) the regular expression. The search versions do the same
    except for the search instead of match regex semantics.

  * New $find(<sequence>, <value>), $find_index(<sequence>, <value>) functions.

    The $find() function returns true if the sequence contains the specified
    value. The $find_index() function returns the index of the first element
    in the sequence that is equal to the specified value or $size(<sequence>)
    if none is found. For string sequences, it's possible to request case-
    insensitive comparison with a flag, for example:

    if ($find ($values, 'foo', icase))
      ...

  * New $integer_sequence(<begin>, <end>[, <step>]) function.

    This function returns the list of uint64 integers starting from <begin>
    (including) to <end> (excluding) with the specified <step> or 1 if
    unspecified. For example:

    hdr = foo.hxx bar.hxx baz.hxx
    src = foo.cxx bar.cxx baz.cxx

    assert ($size($hdr) == $size($src)) "hdr and src expected to be parallel"

    for i: $integer_sequence(0, $size($hdr))
    {
      h = ($hdr[$i])
      s = ($src[$i])
      ...
    }

  * New $is_a(<name>, <target-type>), $filter[_out](<names>, <target-types>)
    functions.

    $is_a() returns true if the <name>'s target type is-a <target-type>. Note
    that this is a dynamic type check that takes into account target type
    inheritance.

    $filter[_out]() return names with target types which are-a (filter) or
    not are-a (filter_out) one of <target-types>.

    In particular, these functions are useful for filtering prerequisite
    targets ($<) in ad hoc recipes and rules.

  * Support for the hex notation for the uint64 type.

    Specifically, now we can do:

    x = [uint64] 0x0000ffff

    cxx.poptions += "-DOFFSET=$x"                 # -DOFFSET=65535
    cxx.poptions += "-DOFFSET=$string($x, 16)"    # -DOFFSET=0xffff
    cxx.poptions += "-DOFFSET=$string($x, 16, 8)" # -DOFFSET=0x0000ffff

    Note that there is no hex notation support for the int64 (signed) type.

  * Support for the `for` and `while` loops in Buildscript recipes and
    Testscript.

    For example:

    for v: $values
      ...
    end

    cat values.txt | for -n v
      ...
    end

    while (!$regex.match(...))
      ...
    end

    See "Command-For" and "Command-While" in the Testscript manual for
    details.

  * New `find` builtin in Buildscript recipes and Testscript.

    For example:

    find gen/ -type f -name '*.?xx' | for -n f
      ...
    end

    See "find" in the Testscript manual for details.

  * Improvements to escape sequence support.

    In the double-quoted strings we now only do effective escaping of the
    special [$("\] characters, line continuations, plus [)] for symmetry.

    There is now support for "escape sequence expansion" in the $\X form where
    \X can be any of the C/C++ simple escape sequences (\n, \t, etc) plus \0
    (which in C/C++ is an octal escape sequence). For example:

    info "foo$\n$\tbar$\n$\tbaz"

    Will print:

    buildfile:1:1: info: foo
             bar
             baz

  * New include_arch installation location and the corresponding
    config.install.include_arch configuration variable.

    This location is meant for architecture-specific files, such as
    configuration headers. By default it's the same as the standard include
    location but can be configured by the user to a different value (for
    example, /usr/include/x86_64-linux-gnu/) for platforms that support
    multiple architectures from the same installation location. This is how
    one would normally use it from a buildfile:

    # The generated configuration header may contain target architecture-
    # specific information so install it into include_arch/ instead of
    # include/.
    #
    h{*}:      install = include/libhello/
    h{config}: install = include_arch/libhello/

  * Support for installation filtering.

    While project authors determine what gets installed at the buildfile
    level, the users of the project can now further filter the installation
    using the config.install.filter variable. For details, see "Installation
    Filtering" in the manual.

  * Support for relocatable installations.

    A relocatable installation can be moved to a directory other than its
    original installation location. To request a relocatable installation, set
    the config.install.relocatable variable to true. For details, see
    "Relocatable Installation" in the manual.

  * Support for installation manifest.

    During the install operation, the config.install.manifest variable can be
    set to a file path (or `-`) in order to write the information about all
    the filesystem entries being installed into the specified file (or
    stdout). The format of the installation manifest is "JSON lines". For
    details, see the config.install.manifest variable documentation in the
    install module.

  * Ability to remap paths in source distributions.

    The dist target-specific variable can now specify a path besides true or
    false. This path is the "imaginary" source location which is used to
    derive the corresponding distribution location. This location can be
    either a directory path (to remap with the same file name) or a file path
    (to remap with a different name). If the path is relative, then it is
    treated relative to the target directory. Note that to make things less
    error-prone, simple paths without any directory separators are not allowed
    (use ./<name> instead).

    Note that if multiple targets end up with the same source location, the
    behavior is undefined and no diagnostics is issued. Note also that such
    remapping has naturally no effect in the bootstrap distribution mode.

  * The in.substitution variable has been renamed to in.mode.

    The original name is still recognized for backwards compatibility.

  * Ability to specify `in` rule substitutions as key-value pairs.

    See "in Module" in the manual for details.

  * New public/private variables model.

    Now unqualified variables are project-private and can be typed, meaning
    that a value assigned to a variable with such a name anywhere within the
    project will have this type. For example:

    [uint64] priority   = [null]
    [uint64] stack_size = [null]

    priority = 1     # Ok.
    stack_size = abc # Error.

    Besides the type, variable attributes can specify visibility (project by
    default) and overridability (false by default). For example:

    thread{*}:
    {
      [uint64, visibility=target] priority   = [null]
      [uint64, visibility=target] stack_size = [null]
    }

    thread{foo}: priority = 1 # Ok.
    priority = 1              # Error.

  * Support for post hoc prerequisites.

    Unlike normal and ad hoc prerequisites, a post hoc prerequisite is built
    after the target, not before. It may also form a dependency cycle together
    with normal/ad hoc prerequisites. In other words, all this form of
    dependency guarantees is that a post hoc prerequisite will be built if its
    dependent target is built.

    A canonical example where this can be useful is a library with a plugin:
    the plugin depends on the library while the library would like to make
    sure the plugin is built whenever the library is built so that programs
    that link the library can be executed without having to specify explicit
    dependency on the plugin (at least for the dynamic linking case):

    lib{hello}: ...
    lib{hello-plugin}: ... lib{hello}
    libs{hello}: libs{hello-plugin}: include = posthoc

    Note that there is no guarantee that post hoc prerequisites will be built
    before the dependents of the target "see" it as built. Rather, it is
    guaranteed that post hoc prerequisites will be built before the end of the
    overall build (more precisely, before the current operation completes).
    As a result, post hoc prerequisites should not be relied upon if the
    result (for example, a source code generator) is expected to be used
    during build (more precisely, within the same operation).

    Note also that the post hoc semantics is not the same as order-only in
    GNU make. In fact, it is an even more "relaxed" form of dependency.
    Specifically, while order-only prerequisite is guaranteed to be built
    before the target, post hoc prerequisite is only guaranteed to be built
    before the end of the overall build.

  * Support for dumping build system state in the JSON format.

    The new --dump-format option can be used to select the desired format.
    Its valid values are `buildfile` and `json-v0.1`. For details on the JSON
    dump format see "Appendix A - JSON Dump Format" in the manual.

  * Change to the --dump option semantics.

    This option now recognizes two additional values: `match-pre` and
    `match-post` to dump the state of pre/post-operations. The `match` value
    now only triggers dumping of the main operation.

  * New --dump-scope and --dump-target options to limit --dump output.

  * New --load-only option in addition to --match-only.

    This option has the effect of loading all the subdirectory buildfiles that
    are not explicitly included and is primarily useful in combination with
    --dump.

  * Quoted/display target names in the JSON structured result are now
    consistent with the JSON dump.

    Specifically, before we had `target` (display) and `quoted_target` and now
    we have `target` (quoted) and `display_target`. Note that this is a
    backwards-incompatible change.

  * The dist meta-operation no longer invokes the install program.

    This results in a substantial speedup, especially on Windows. The use of
    install (or another install-like program) can still be forced with
    explicit config.dist.cmd=install.

  * Clang -Wunqualified-std-cast-call warning was remapped to -Wextra.

    Clang 15 introduced the -Wunqualified-std-cast-call warning which warns
    about unqualified calls to std::move() and std::forward() (because they
    can be "hijacked" via ADL). Surprisingly, this warning is enabled by
    default, as opposed to with -Wextra or at least -Wall. It has also proven
    to be quite disruptive, causing a large number of warnings in a large
    number of packages. So we have "remapped" it to -Wextra for now and in the
    future may "relax" it to -Wall and potentially to being enabled by
    default. See GitHub issue #259 for background and details.

Version 0.15.0

  * Generated C/C++ headers and ad hoc sources are now updated during match.

    Specifically, all headers as well as ad hoc headers and sources are now
    treated by the cc::link_rule as if they had update=match unless explicit
    update=execute is specified (see below on the update operation-specific
    variable).

    This change should be transparent to most projects. For background and
    discussion of rare cases where you may wish to disable this, see:

    https://github.com/build2/HOWTO/blob/master/entries/handle-auto-generated-headers.md

  * Support for rule hints.

    A rule hint is a target attribute, for example:

    [rule_hint=cxx] exe{hello}: c{hello}

    Rule hints can be used to resolve ambiguity when multiple rules match the
    same target as well as to override an unambiguous match.

    In cc::link_rule we now support "linking" libraries without any sources or
    headers with a hint. This can be useful for creating "metadata libraries"
    whose only purpose is to convey metadata (options to use and/or libraries
    to link).

  * UTF-8 is now the default input/source character set for C/C++ compilation.

    Specifically, the cc module now passes the appropriate compiler option
    (/utf-8 for MSVC and -finput-charset=UTF-8 for GCC and Clang) unless a
    custom value is already specified (with /{source,execution}-charset for
    MSVC and -finput-charset for GCC and Clang).

    This change may trigger new compilation errors in your source code if
    it's not valid UTF-8 (such errors most commonly point into comments).
    For various ways to fix this, see:

    https://github.com/build2/HOWTO/blob/master/entries/convert-source-files-to-utf8.md

  * Project configuration variables are now non-nullable by default.

    A project configuration variable with the NULL default value is naturally
    assumed nullable, for example:

    config [string] config.libhello.fallback_name ?= [null]

    Otherwise, to make a project configuration nullable use the `null`
    variable attribute, for example:

    config [string, null] config.libhello.fallback_name ?= "World"

  * New $relative(<path>, <dir-path>) function.

  * New $root_directory(<path>) function.

  * New $size() function to get the size of string, path, dir_path.

  * New $size() function to get the size of a sequence (strings, paths, etc).

  * New $sort() function to sort a sequence (strings, paths, etc).

    The function has the following signature:

    $sort(<sequence> [, <flags>])

    The following flag is supported by all the overloads:

      dedup - in addition to sorting also remove duplicates

          Additionally, the strings overload also support the following flag:

      icase - sort ignoring case

    Note that on case-insensitive filesystems the paths and dir_paths
    overloads' order is case-insensitive.

  * New $config.origin() function for querying configuration value origin.

    Give a config.* variable name, this function returns one of `undefined`,
    `default`, `buildfile`, or `override`.

  * Recognition of -pthread as a special -l option in *.libs.

    For background, see:

    https://github.com/build2/HOWTO/blob/master/entries/link-pthread.md

  * The bin.whole (whole archive) value is now saved in generated pkg-config
    files.

  * Ability to customize header and library search paths in generated
    pkg-config files.

    Specifically, {cc,c,cxx}.pkgconfig.{include,lib} variables specify header
    (-I) and library (-L) search paths to use in the generated pkg-config
    files instead of the default install.{include,lib}. Relative paths are
    resolved as installation paths. For example:

    lib{Qt6Core}: cxx.pkgconfig.include = include/qt6/

  * Ability to save user metadata in C/C++ libraries, including in generated
    pkg-config files.

    For background and details, see:

    https://github.com/build2/HOWTO/blob/master/entries/convey-additional-information-with-exe-lib.md

  * Support for rule-specific search in immediate import.

    We can now nominate a rule to perform the rule-specific search (if
    required) using the rule_hint attribute. For example:

    import! [metadata, rule_hint=cxx.link] lib = libhello%lib{hello}

  * Support for dynamic dependencies in ad hoc recipes.

    Specifically, the `depdb` builtin now has the new `dyndep` command that
    can be used to extract dynamic dependencies from program output or a
    file. For example, from program output:

    obje{hello.o}: cxx{hello}
    {{
      s = $path($<[0])
      o = $path($>)

      poptions = $cxx.poptions $cc.poptions
      coptions = $cc.coptions $cxx.coptions

      depdb dyndep $poptions --what=header --default-type=h -- \
        $cxx.path $poptions $coptions $cxx.mode -M -MG $s

      diag c++ ($<[0])

      $cxx.path $poptions $coptions $cxx.mode -o $o -c $s
    }}

    Or, alternatively, from a file:

    t = $(o).t
    depdb dyndep $poptions --what=header --default-type=h --file $t -- \
      $cxx.path $poptions $coptions $cxx.mode -M -MG $s >$t

    The above depdb-dyndep commands will run the C++ compiler with the -M -MG
    options to extract the header dependency information, parse the resulting
    make dependency declaration (either from stdout or from file) and enter
    each header as a prerequisite of the obje{hello.o} target, as if they were
    listed explicitly. It will also save this list of headers in the auxiliary
    dependency database (hello.o.d file) in order to detect changes to these
    headers on subsequent updates. The --what option specifies what to call
    the dependencies being extracted in diagnostics. The --default-type option
    specifies the default target type to use for a dependency if its file name
    cannot be mapped to a target type.

    The above depdb-dyndep variant extracts the dependencies ahead of the
    compilation proper and will handle auto-generated headers (see the -MG
    option for details) provided we pass the header search paths where they
    could be generated with the -I options (passed as $poptions in the above
    example).

    If there can be no auto-generated dependencies or if they can all be
    listed explicitly as static prerequisites, then we can use a variant of
    the depdb-dyndep command that extracts the dependencies as a by-product of
    compilation. In this mode only the --file input is supported. For example
    (assuming hxx{config} is auto-generated):

    obje{hello.o}: cxx{hello} hxx{config}
    {{
      s = $path($<[0])
      o = $path($>)
      t = $(o).t

      poptions = $cxx.poptions $cc.poptions
      coptions = $cc.coptions $cxx.coptions

      depdb dyndep --byproduct --what=header --default-type=h --file $t

      diag c++ ($<[0])

      $cxx.path $poptions $coptions $cxx.mode -MD -MF $t -o $o -c $s
    }}

    Other options supported by the depdb-dyndep command:

    --format <name>

      Dependency format. Currently only the `make` dependency format is
      supported and is the default.

    --cwd <dir>

      Working directory used to complete relative dependency paths. This
      option is currently only valid in the --byproduct mode (in the normal
      mode relative paths indicate non-existent files).

    --adhoc

      Treat dynamically discovered prerequisites as ad hoc (so they don't end
      up in $<; only in the normal mode).

    --drop-cycles

      Drop prerequisites that are also targets. Only use this option if you
      are sure such cycles are harmless, that is, the output is not affected
      by such prerequisites' content.

    --update-{include,exclude} <tgt>|<pat>

      Prerequisite targets/patterns to include/exclude (from the static
      prerequisite set) for update during match (those excluded will be
      updated during execute). The order in which these options are specified
      is significant with the first target/pattern that matches determining
      the result. If only the --update-include options are specified, then
      only the explicitly included prerequisites will be updated. Otherwise,
      all prerequisites that are not explicitly excluded will be updated. If
      none of these options is specified, then all the static prerequisites
      are updated during match. Note also that these options do not apply to
      ad hoc prerequisites which are always updated during match.

    The common use-case for the --update-exclude option is to omit updating
    a library which is only needed to extract exported preprocessor options.
    Here is a typical pattern:

    import libs = libhello%lib{hello}

    libue{hello-meta}: $libs

    obje{hello.o}: cxx{hello} libue{hello-meta}
    {{
      s = $path($<[0])
      o = $path($>)

      lib_poptions = $cxx.lib_poptions(libue{hello-meta}, obje)
      depdb hash $lib_poptions

      poptions  = $cxx.poptions $cc.poptions $lib_poptions
      coptions  = $cc.coptions $cxx.coptions

      depdb dyndep $poptions --what=header --default-type=h \
        --update-exclude libue{hello-meta} -- \
          $cxx.path $poptions $coptions $cxx.mode -M -MG $s

      diag c++ ($<[0])

      $cxx.path $poptions $coptions $cxx.mode -o $o -c $s
    }}

    As another example, sometimes we need to extract the "common interface"
    preprocessor options that are independent of the the library type (static
    or shared). For example, the Qt moc compiler needs to "see" the C/C++
    preprocessor options from imported libraries if they could affect its
    input. Here is how we can implement this:

    import libs = libhello%lib{hello}

    libul{hello-meta}: $libs

    cxx{hello-moc}: hxx{hello} libul{hello-meta} $moc
    {{
      s = $path($<[0])
      o = $path($>[0])
      t = $(o).t

      lib_poptions = $cxx.lib_poptions(libul{hello-meta})
      depdb hash $lib_poptions

      depdb dyndep --byproduct --drop-cycles --what=header --default-type=h \
        --update-exclude libul{hello-meta} --file $t

      diag moc ($<[0])

      $moc $cc.poptions $cxx.poptions $lib_poptions \
        -f $leaf($s) --output-dep-file --dep-file-path $t -o $o $s
    }}

    Planned future improvements include support for the `lines` (list of
    files, one per line) input format in addition to `make` and support for
    dynamic targets in addition to prerequisites.

  * Support for specifying custom ad hoc pattern rule names.

    Besides improving diagnostics, this allows us to use such a name in the
    rule hints, for example:

    [rule_name=hello.link] exe{~'/(.*)/'}: obje{~'/\1/'}
    {{
      $cxx.path -o $path($>) $path($<[0])
    }}

    [rule_hint=hello] exe{hello}: obje{hello}

    obje{hello}: c{hello-c}

  * Ability to disfigure specific configuration variables.

    The new config.config.disfigure variable can be used to specify the list
    of variables to ignore when loading config.build (and any files specified
    in config.config.load), letting them to take on the default values. For
    example:

    $ b configure config.config.disfigure=config.hello.fancy

    Besides names, variables can also be specified as patterns in the
    config.<prefix>.(*|**)[<suffix>] form where `*` matches single
    component names (i.e., `foo` but not `foo.bar`), and `**` matches
    single and multi-component names. Currently only single wildcard (`*` or
    `**`) is supported.  Additionally, a pattern in the config.<prefix>(*|**)
    form (i.e., without `.` after <prefix>) matches config.<prefix>.(*|**)
    plus config.<prefix> itself (but not config.<prefix>foo).

    For example, to disfigure all the project configuration variables (while
    preserving all the module configuration variables; note quoting to prevent
    pattern expansion):

    $ b config.config.disfigure="'config.hello**'"

  * Ability to omit loading config.build.

    If the new config.config.unload variable is set to true, then omit loading
    the project's configuration from the config.build file. Note that the
    configuration is still loaded from config.config.load if specified. Note
    also that similar to config.config.load, only overrides specified on this
    project's root scope and global scope are considered.

  * Ability to match libul{} targets.

    The bin.libul rule picks, matches, and unmatches (if possible) a member
    for the purpose of making its metadata (for example, library's poptions,
    if it's one of the cc libraries) available.

  * Ability to get common interface options via ${c,cxx}.lib_poptions().

    Specifically, the output target type may now be omitted for utility
    libraries (libul{} and libu[eas]{}). In this case, only "common interface"
    options will be returned for lib{} dependencies. This is primarily useful
    for obtaining poptions to be passed to tools other than C/C++ compilers
    (for example, Qt moc).

  * Ability to control -I translation to -isystem or /external:I in
    ${c,cxx}.lib_poptions().

    See the function documentation for details.

  * New `update` operation-specific variable.

    This variable is similar to the already existing `clean` and `test`
    variables but besides the standard `true` and `false` values, it can also
    be set to `unmatch` (match but do not update) and `match` (update during
    match) and `execute` (update during execute, as is normally; this value is
    primarily useful if the rule has the `match` semantics by default).

    Note that the unmatch (match but do not update) and match (update during
    match) values are only supported by certain rules (and potentially only
    for certain prerequisite types).

    Additionally:

    - All the operation-specific variables are now checked for `false` as an
      override for the prerequisite-specific `include` variable. This can now
      be used to disable a prerequisite for update, for example:

      ./: exe{test}: update = false

    - Ad hoc Buildscript recipes now support update=unmatch|match.

    - The cc::link_rule now supports the `match` value for headers and ad hoc
      prerequisites. This can be used to make sure all the library headers are
      updated before matching any of its (or dependent's) object files.

  * New build.mode global scope variable.

    This variable signals the mode the build system may be running in. The two
    core modes are `no-external-modules` (bootstrapping of external modules is
    disabled, see --no-external-modules for details) and `normal` (normal
    execution). Other build system drivers may invent additional modes (for
    example, the bpkg `skeleton` mode; see "Package Build System Skeleton" in
    the package manager manual for details).

  * New cmdline value type for canned command lines.

    The Testscript and Buildscript languages now use the special cmdline value
    type for canned command lines. Specifically, the re-lexing after expansion
    now only happens if the expended value is of the cmdline type. See
    "Lexical Structure" in the Testscript manual for details.

  * The bash build system module now installs bash modules into
    bin/<project>.bash/ instead of bin/<project>/ to avoid clashes.

  * New --trace-{match,execute} options.

    These options can be used to understand which dependency chain causes
    matching or execution of a particular target. See b(1) for details.

  * JSON format support for the --structured-result option and the info meta
    operation.

    See b(1) for details.

  * Switch to using libpkg-config instead of libpkfconf for loading pkg-config
    files.

Version 0.14.0

  * Support for hermetic build configurations.

    Hermetic build configurations save environment variables that affect the
    project along with other project configuration in the config.build file.
    These saved environment variables are then used instead of the current
    environment when performing operations on the project, thus making sure
    the project "sees" exactly the same environment as during configuration.
    The built-in ~host and ~build2 configurations are now hermetic.

    Hermetic configuration support is built on top of the lower-level
    config.config.environment configuration variable which allows us to save a
    custom set of environment variables/values.

    As part of this work we now also track changes to the environment in non-
    hermetic configurations and automatically rebuild affected targets.

    See "Hermetic Build Configurations" in the manual for details.

  * Support for ad hoc regex pattern rules.

    An ad hoc pattern rule consists of a pattern that mimics a dependency
    declaration followed by one or more recipes. For example:

    exe{~'/(.*)/'}: cxx{~'/\1/'}
    {{
      $cxx.path -o $path($>) $path($<[0])
    }}

    If a pattern matches a dependency declaration of a target, then the recipe
    is used to perform the corresponding operation on this target. For
    example, the following dependency declaration matches the above pattern
    which means the rule's recipe will be used to update this target:

    exe{hello}: cxx{hello}

    While the following declarations do not match the above pattern:

    exe{hello}:   c{hello}  # Type mismatch.
    exe{hello}: cxx{howdy}  # Name mismatch.

    On the left hand side of `:` in the pattern we can have a single target or
    an ad hoc target group. The single target or the first (primary) ad hoc
    group member must be a regex pattern (~). The rest of the ad hoc group
    members can be patterns or substitutions (^). For example:

    <exe{~'/(.*)/'} file{^'/\1.map/'}>: cxx{~'/\1/'}
    {{
      $cxx.path -o $path($>[0]) "-Wl,-Map=$path($>[1])" $path($<[0])
    }}

    On the right hand side of `:` in the pattern we have prerequisites which
    can be patterns, substitutions, or non-patterns. For example:

    <exe{~'/(.*)/'} file{^'/\1.map/'}>: cxx{~'/\1/'} hxx{^'/\1/'} hxx{common}
    {{
      $cxx.path -o $path($>[0]) "-Wl,-Map=$path($>[1])" $path($<[0])
    }}

    Substitutions on the left hand side of `:` and substitutions and non-
    patterns on the right hand side are added to the dependency declaration.
    For example, given the above rule and dependency declaration, the
    effective dependency is going to be:

    <exe{hello} file{hello.map}>: cxx{hello} hxx{hello} hxx{common}

    Similar to ad hoc recipes, ad hoc rules can be written in Buildscript or
    C++.

  * Support for regex patterns in target type/pattern-specific variables.

    This is in addition to the already supported path patterns. For example:

    hxx{*}:     x = y  # path pattern
    hxx{~/.*/}: x = y  # regex pattern

  * New pre-defined semantics for the config.<project>.develop variable.

    This variable allows a project to distinguish between development and
    consumption builds. While normally there is no distinction, sometimes a
    project may need to provide additional functionality during development.
    For example, a source code generator which uses its own generated code in
    its implementation may need to provide a bootstrap step from the pre-
    generated code. Normally, such a step is only needed during development.

    If used, this variable should be explicitly defined by the project with
    the bool type and the false default value. For example:

    config [bool] config.hello.develop ?= false

    See "Project Configuration" in the manual for details.

  * Support for warning suppression from external C/C++ libraries.

    This is implemented by defining a notion of a project's internal scope and
    automatically translating header search path options (-I) exported by
    libraries that are outside of the internal scope to appropriate "external
    header search path" options (-isystem for GCC/Clang, /external:I for MSVC
    16.10 and later). In the future this functionality will be extended to
    side-building BMIs for external module interfaces and header units.

    Note that this functionality is not without limitations and drawbacks and,
    if needed, should be enabled explicitly. See the "Compilation Internal
    Scope" section in the manual for details.

  * C++20 modules support in GCC 11 using the module mapper.

    This support covers all the major C++20 modules features including named
    modules, module partitions (both interface and implementation), header
    unit importation, and include translation. All of these features are also
    supported in libraries, including consumption of installed libraries with
    information about modules and importable headers conveyed in pkg-config
    files. Module interface-only libraries are also supported.

    Note that one area that is not yet well supported (due to module mapper
    limitations) is auto-generated headers. Also note that as of version 11,
    support for modules in GCC is still experimental and incomplete.

  * Support for automatic DLL symbol exporting.

    It is now possible to automatically generate a .def file that exports all
    symbols from a Windows DLL. See "Automatic DLL Symbol Exporting" in the
    manual for details.

  * Initial Emscripten compiler support.

    - Target: wasm32-emscripten (wasm32-unknown-emscripten).

    - Compiler id: clang-emscripten (type clang, variant emscripten, class
      gcc).

    - Ability to build executables (.js plus .wasm) and static libraries (.a).
      Set executable bit on the .js file (so it can be executed with a
      suitable binfmt interpreter). Track the additional .worker.js file if
      -pthread is specified.

    - Default config.bin.lib for wasm32-emscripten is static instead of both.

    - Full C++ exception support is enabled by default unless disabled
      explicitly by the user with -s DISABLE_EXCEPTION_CATCHING=1|2.

    - The bin module registers the wasm{} target type for wasm32-emscripten.

  * New string functions: $string.trim(), $string.lcase(), $string.ucase().

  * Support for test runners (config.test.runner).
    Support for test timeouts (config.test.timeout).

    See "test Module" in the manual for details.

  * New <version> install directory substitution in addition to <project>.
    New config.install.etc variable with the data_root/etc/ default.

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

  * Support for fallback substitution in the in module (in.null variable).

    See "in Module" in the manual for details.

  * New export pseudo-builtin that allows adding/removing variables to/from
    the current scope's commands execution environment.

    See the Testscript manual for details.

  * New ad hoc recipe depdb preamble.

    The Buildscript language now provides a new pseudo-builtin, depdb, that
    allows tracking of custom auxiliary dependency information. Invocations of
    this builtin should come before any recipe commands and are collectively
    called the depdb preamble. Non-pure functions can now only be called as
    part of this preamble. For example:

    file{output}: file{input} $foo
    {{
      diag foo $>
      depdb env FOO                 # foo uses the FOO environment variable
      $foo $path($<[0]) >$path($>)
    }}

  * New ${c,cxx}.deduplicate_export_libs() functions.

    These functions deduplicate interface library dependencies by removing
    libraries that are also interface dependencies of other libraries on the
    specified list. This can lead to a significantly better build performance
    for heavily interface-interdependent library families (for example, like
    Boost). Typical usage:

    import intf_libs = ...
    import intf_libs += ...
    ...
    import intf_libs += ...
    intf_libs = $cxx.deduplicate_export_libs($intf_libs)

  * New ${c,cxx}.find_system_{header,library}() functions.

    These functions can be used to detect the presence of a header/library in
    one of the system header/library search directories.

  * New ${c,cxx}.lib_{poptions,libs,rpaths}() and $cxx.obj_modules() functions.

    These functions can be used to query library metadata for options and
    libraries that should be used when compiling/linking dependent targets,
    similar to how cc::{compile,link}_rule do it. With this support it should
    be possible to more or less re-create their semantics in ad hoc recipes.

  * Support for suppressing duplicates when extracting library options and
    linking libraries in cc::{compile,link}_rule.

  * The cxx.std=latest value has been mapped to c++2b for Clang 13 or later
    and to /std:c++20 for MSVC 16.11 or later.

  * Support for LTO parallelization during linking in GCC and Clang.

    GCC >= 10 and Clang >= 4 support controlling the number of LTO threads
    used during linking. The cc::link_rule now uses the build system scheduler
    to automatically allocate up to the number of available threads to the GCC
    or Clang linker processes when -flto=auto or -flto=thin is specified,
    respectively.

  * /Zc:__cplusplus is now passed by default starting from MSVC 15.7.

    This can be overridden by passing a variant of this option as part of the
    compiler mode options.

  * Support for disabling clean through target-prerequisite relationships.

    The current semantics is to clean any prerequisites that are in the same
    project (root scope) as the target and it may seem more natural to rather
    only clean prerequisites that are in the same base scope. While it's often
    true for simple projects, in more complex cases it's not unusual to have
    common intermediate build results (object files, utility libraries, etc)
    residing in the parent and/or sibling directories. With such arrangements,
    cleaning only in base may leave such intermediate build results laying
    around since there is no reason to list them as prerequisites of any
    directory aliases.

    So we clean in the root scope by default but now any target-prerequisite
    relationship can be marked not to trigger a clean with the clean=false
    prerequisite-specific value. For example:

    man1{cli}: exe{cli}: clean = false # Don't clean the man generation tool.

  * exe{} targets are no longer installed through target-prerequisite
    relationships of file-based targets.

    Normally, an exe{} that is listed as a prerequisite of a file-based target
    is there to be executed (for example, to generate that target) and not to
    trigger its installation (such an exe{} would typically be installed via
    the ./ alias). This default behavior, however, can be overridden with the
    install=true prerequisite-specific value. For example:

    exe{foo}: exe{bar}: install = true  # foo runs bar

  * Consistently install prerequisites from any scope by default.

    It is also now possible to adjust this behavior with the global
    !config.install.scope override. Valid values for this variable are:

    project -- only from project
    bundle  -- from bundle amalgamation
    strong  -- from strong amalgamation
    weak    -- from weak amalgamation
    global  -- from all projects (default)

  * Variable names/components that start with underscore as well as variables
    in the build, import, and export namespaces are now reserved by the build
    system core. For example:

    _x = 1       # error
    x._y = 1     # error
    build.x = 1  # error

  * New int64 (signed 64-bit integer) and int64s (vector of such integers)
    variable types.

  * Default options files can now contain global variable overrides.

  * Support for multiple -e options (scripts) in the sed builtin.

  * The bin.lib.version variable no longer needs to include leading `@` for
    platform-independent versions.

  * The actualize mode of $path.normalize() is now provided by a separate
    $path.actualize() function.

  * New --options-file build system driver option that allows specifying
    additional options in a file.

  * New notion of bundle amalgamation which is defined as the outermost named
    strong (source-based) amalgamation.

  * Support for unseparated scope-qualified variable assignment and expansion.

    For example, now the following:

    foo/x = y
    info $(foo/x)

    Is equivalent to:

    foo/ x = y
    info $(foo/ x)

    While this makes scope-qualified syntax consistent with target-qualified,
    it also means that variable names that contain directory separators are
    now effectively reserved.

  * New bootstrap distribution mode (!config.dist.bootstrap=true).

    In this mode the dist meta-operation does not load the project (but does
    bootstrap it) and adds all the source files into the distribution only
    ignoring files and directories that start with a dot. This mode is
    primarily meant for situations where the project cannot (yet) be loaded
    due to missing dependencies.

  * Support for external build system modules that require bootstrap (that is,
    loaded in bootstrap.build). See also the new --no-external-modules option.

  * New file cache for intermediate build results.

    The file cache is used to store intermediate build results, for example,
    partially-preprocessed C/C++ translation units (those .i/.ii files). The
    cache implementation to use is controlled by the new --file-cache option.
    Its valid values are noop (no caching or compression) and sync-lz4 (no
    caching with synchronous LZ4 on-disk compression; this is the default).

  * New BUILD2_DEF_OPT environment variable that can be used to suppress
    loading of default options files.

  * New BUILD2_DEF_OVR environment variable that can be used to propagate
    global variable overrides to nested build system invocations.

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.

Version 0.12.0

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

    See the libbuild2-hello sample module to get started:

    https://github.com/build2/libbuild2-hello

  * 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
    example:

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

    But:

    $ 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:

    https://github.com/build2/build2/issues/34

  * 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@1.2

    And end up with:

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

    See issue #49 for background and details:

    https://github.com/build2/build2/issues/49

  * 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
    example:

    $ 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
    example:

    $ 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.

    Before:

    x = [string null]

    After:

    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:

    https://lists.build2.org/archives/users/2019-October/000687.html

    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:

    LIBBUILD2_MTIME_CHECK
    LIBBUILD2_SANE_STACK_SIZE
    LIBBUILD2_DEFAULT_STACK_SIZE
    LIBBUILD2_ATOMIC_NON_LOCK_FREE

  * 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
    build.

  * 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
    versions.

  * Rename the config.cxx.importable_headers variable to
    config.cxx.translatable_headers.

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

  * 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
    example:

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

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

Version 0.11.0

  * Initial work on header unit importation and include translation support.

    In particular, for GCC, the (experimental) module mapper approach is now
    used to handle header unit importation, include translation, and headers
    dependency extraction, all with support for auto-generated headers.

  * Generalized target/prerequisite variable blocks.

    Target/prerequisite-specific variable blocks can now be present even if
    there are prerequisites. For example, now instead of:

    exe{foo}: cxx{foo}
    exe{foo}: cc.loptions += -rdynamic

    Or:

    exe{foo}: cxx{foo}
    exe{foo}:
    {
      cc.loptions += -rdynamic
      cc.libs += -ldl
    }

    We can write:

    exe{foo}: cxx{foo}
    {
      cc.loptions += -rdynamic
      cc.libs += -ldl
    }

    This also works with dependency chains in which case the block applies to
    the set of prerequisites (note: not targets) before the last ':'. For
    example:

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

  * Support for ad hoc target groups.

    In certain cases we may need to instruct the underlying tool (compiler,
    linker, etc) to produce additional outputs. For example, we may want to
    request the compiler to produce an assembler listing or the linker to
    produce a map file. While we could already pass the required options, the
    resulting files will not be part of the build state. Specifically, they
    will not be cleaned up and we cannot use them as prerequisites of other
    targets.

    Ad hoc target groups allow us to specify that updating a target produces
    additional outputs, called ad hoc group members. For example:

    <exe{hello} file{hello.map}>: cxx{hello}
    {
      cc.loptions += "-Wl,-Map=$out_base/hello.map"
    }

    <obje{hello} file{hello.lst}>:
    {
      cc.coptions += "-Wa,-amhls=$out_base/hello.lst"
    }

    Note also that all things ad hoc (prerequisites, targets, rules) are still
    under active development so further improvements (such as not having to
    repeat names twice) are likely.

  * New config.{c,cxx}.std configuration variables that, if present, override
    {c,cxx}.std specified at the project level.

    In particular, this allows forcing a specific standard for all the
    projects in a build configuration, for example:

    $ b create: exp-conf/,cc config.cxx=g++ config.cxx.std=experimental

  * New --dry-run|-n option instructs build rules to print commands without
    actually executing them.

    Note that commands that are required to create an accurate build state
    will still be executed and the extracted auxiliary dependency information
    saved. In other words, this is not the "don't touch the filesystem" mode
    but rather "do minimum amount of work to show what needs to be done". In
    particular, this mode is useful to quickly generate the compilation
    database, for example:

    $ b -vn clean update |& compiledb

  * Ability to disable automatic rpath, support for custom rpath-link.

    Specifically, the new config.bin.rpath.auto variable can be used to
    disable the automatic addition of prerequisite library rpaths, for
    example:

    $ b config.bin.rpath.auto=false

    Note that in this case rpath-link is still added where normally required
    and for target platforms that support it (Linux and *BSD).

    The new config.bin.rpath_link and config.bin.rpath_link.auto have the same
    semantics as config.bin.rpath* but for rpath-link.

  * Enable MSVC strict mode (/permissive-) for 'experimental' standard
    starting from version 15.5.

Version 0.10.0

  * Support for an alternative build file/directory naming scheme.

    Now the build/*.build, buildfile, and .buildignore filesystem entries in a
    project can alternatively (but consistently) be called build2/*.build2,
    build2file, and .build2ignore. See a note at the beginning of the "Project
    Structure" section in the manual for details (motivation, restrictions,
    etc).

  * Support for multiple variable overrides.

    Now we can do:

    $ b config.cxx.coptions=-O3 config.cxx.coptions=-O0

    Or even:

    $ b config.cxx.coptions=-O3 config.cxx.coptions+=-g

  * Support for MSVC 16 (2019).

  * Support for automatic switching to option files (AKA response files) on
    Windows if the linker command line is too long.

    This covers both MSVC link.exe/lib.exe and MinGW gcc.exe/ar.exe.

Version 0.9.0

  * New "Diagnostics and Debugging" section in the manual on debugging build
    issues.

  * Support for dependency chains.

    Now instead of:

    ./: exe{foo}
    exe{foo}: cxx{*}

    We can write:

    ./: exe{foo}: cxx{*}

    Or even:

    ./: exe{foo}: libue{foo}: cxx{*}

    This can be combined with prerequisite-specific variables (which naturally
    only apply to the last set of prerequisites in the chain):

    ./: exe{foo}: libue{foo}: bin.whole = false

  * Support for target and prerequisite specific variable blocks.

    For example, now instead of:

    lib{foo}: cxx.loptions += -static
    lib{foo}: cxx.libs += -lpthread

    We can write:

    lib{foo}:
    {
      cxx.loptions += -static
      cxx.libs += -lpthread
    }

    The same works for prerequisites as well as target type/patterns. For
    example:

    exe{*.test}:
    {
      test = true
      install = false
    }

  * Fallback to loading outer buildfile if there isn't one in the target's
    directory (src_base).

    This covers the case where the target is defined in the outer buildfile
    which is common with non-intrusive project conversions where everything is
    built from a single root buildfile.

  * Command line variable override scope syntax is now consistent with
    buildfile syntax.

    Before:

    $ b dir/:foo=bar ...

    After:

    $ b dir/foo=bar

    Alternatively (the buildfile syntax):

    $ b 'dir/ foo=bar'

    Note that the (rarely used) scope visibility modifier now leads to a
    double slash:

    $ b dir//foo=bar

  * Support for relative to base scope command line variable overrides.

    Currently, if we do:

    $ b dir/ ./foo=bar

    The scope the foo=bar is set on is relative to CWD, not dir/. While this
    may seem wrong at first, this is the least surprising behavior when we
    take into account that there can be multiple dir/'s.

    Sometimes, however, we do want the override directory to be treated
    relative to (every) target's base scope that we are building. To support
    this we are extending the '.' and '..' special directory names (which are
    still resolved relative to CWD) with '...', which means "relative to the
    base scope of every target in the buildspec". For example:

    $ b dir/ .../foo=bar

    Is equivalent to:

    $ b dir/ dir/foo=bar

    And:

    $ b liba/ libb/ .../tests/foo=bar

    Is equivalent to:

    $ b liba/ libb/ liba/tests/foo=bar libb/tests/foo=bar

  * New config.{c,cxx}.{id,version,target} configuration variables.

    These variables allow overriding guessed compiler id/version/target, for
    example, in case of mis-guesses or when working with compilers that don't
    report their base (e.g., GCC, Clang) with -v/--version (common in the
    embedded space).

  * New --[no-]mtime-check options to control backwards modification time
    checks at runtime.

    By default the checks are enabled only for the staged toolchain.

  * New --dump <phase> option, remove state dumping from verbosity level 6.

  * The info meta-operation now prints the list of operations and meta-
    operations supported by the project.

  * New sleep Testscript builtin.

Version 0.8.0

  * BREAKING: rename the .test extension (Testscript file) to .testscript and
    the test{} target type to testscript{}.

  * Introduction chapter in the build system manual.

    The introduction covers every aspect of the build infrastructure,
    including the underlying concepts, for the canonical executable and
    library projects as produced by bdep-new(1).

  * New 'in' build system module.

    Given test.in containing something along these lines:

    foo = $foo$

    Now we can do:

    using in

    file{test}: in{test.in}
    file{test}: foo = FOO

    The alternative variable substitution symbol can be specified with the
    in.symbol variable and lax (instead of the default strict) mode with
    in.mode. For example:

    file{test}: in.symbol = '@'
    file{test}: in.mode = lax

  * New 'bash' build system module that provides modularization support for
    bash scripts. See the build system manual for all the details.

  * Support for 'binless' (binary-less aka header-only) libraries.

    A header-only library (or, in the future, a module interface-only library)
    is not a different kind of library compared to static/shared libraries but
    is rather a binary-less, or binless for short, static or shared library.
    Whether a library is binless is determined dynamically and automatically
    based on the absence of source file prerequisites. See the build system
    manual for details.

  * Use thin archives for utility libraries if available.

    Thin archives are supported by GNU ar since binutils 2.19.1 and LLVM ar
    since LLVM 3.8.0.

  * Support for archive checksum generation during distribution:

    Now we can do:

    $ b dist: ... \
    config.dist.archives='tar.gz zip' \
    config.dist.checksums='sha1 sha256'

    And end up with .tar.gz.sha1, .tar.gz.sha256, .zip.sha1, and .zip.sha256
    checksum files in addition to archives.

  * Support for excluded and ad hoc prerequisites:

    The inclusion/exclusion is controlled via the 'include' prerequisite-
    specific variable. Valid values are:

    false  - exclude
    true   - include
    adhoc  - include but treat as an ad hoc input

    For example:

    lib{foo}: cxx{win32-utility}: include = ($cxx.targe.class == 'windows')
    exe{bar}: libs{plugin}: include = adhoc

  * C++ Modules support:

    - handle the leading 'module;' marker (p0713)
    - switch to new GCC module interface (-fmodule-mapper)
    - force reprocessing for module interface units if compiling with MSVC

  * Testscript:

    - new mv builtin
    - new --after <ref-file> option in touch builtin

  * New $process.run() and $process.run_regex() functions:

    $process.run(<prog>[ <args>...])

    Return trimmed stdout.

    $process.run_regex(<prog>[ <args>...], <pat> [, <fmt>])

    Return stdout lines matched and optionally processed with regex.

    Each line of stdout (including the customary trailing blank) is matched
    (as a whole) against <pat> and, if successful, returned, optionally
    processed with <fmt>, as an element of a list.

  * Support for name patterns without wildcard characters.

    In particular, this allows the "if-exists" specification of prerequisites,
    for example:

    for t: $tests
      exe{$t}: cxx{$t} test{+$t}

  * Functions for decomposing name as target/prerequisite name:

    $name.name()
    $name.extension()
    $name.directory()
    $name.target_type()
    $name.project()

  * Add support for default extension specification, trailing dot escaping.

    For example:

    cxx{*}: extension = cxx

    cxx{foo}         # foo.cxx
    cxx{foo.test}    # foo.test      (probably what we want...)
    cxx{foo.test...} # foo.test.cxx  (... is this)
    cxx{foo..}       # foo.
    cxx{foo....}     # foo..
    cxx{foo.....}    # error (must come in escape pairs)

  * Use (native) C and C++ compilers we were built with as defaults for
    config.c and config.cxx, respectively.

  * Implement missing pieces in utility libraries support. In particular, we
    can now build static libraries out of utility libraries.

  * Built-in support for Windows module definition files (.def/def{}).

  * Project names are now sanitized when forming the config.import.<proj>
    variables. Specifically, '-', '+', and '.' are replaced with '_' to form a
    "canonical" variable name.

Version 0.7.0

  * Initial support for Clang targeting MSVC runtime (native Clang interface,
    not the clang-cl wrapper).

  * C++ Modules TS introduction, build system support, and design guidelines
    documentation.

  * New {c,cxx}.guess modules.

    These can be loaded before {c,cxx} to guess the compiler. Based on this
    information we can then choose the standard, experimental features, etc.
    For example:

    using cxx.guess

    if ($cxx.id == 'clang')
      cxx.features.modules = false

    cxx.std = experimental

    using cxx

  * New {c,cxx}.class variables.

    Compiler class describes a set of compilers that follow more or less the
    same command line interface. Compilers that don't belong to any of the
    existing classes are in classes of their own (say, Sun CC would be on its
    own if we were to support it).

    Currently defined compiler classes:

    gcc   gcc, clang, clang-apple, icc (on non-Windows)
    msvc  msvc, clang-cl, icc (Windows)

  * Support for C/C++ runtime/stdlib detection ({c,cxx}.{runtime,stdlib}
    variables; see cc/guess.hxx for possible values).

  * New __build2_preprocess macro.

    If cc.reprocess is true, the __build2_preprocess is defined during
    dependency extraction. This can be used to work around separate
    preprocessing bugs in the compiler.

  * Support for for-loop. The semantics is similar to the C++11 range-based
    for:

    list = 1 2 3
    for i: $list
      print $i

    Note that there is no scoping of any kind for the loop variable ('i' in
    the above example). In the future the plan is to also support more general
    while-loop as well as break and continue.

  * New info meta operation.

    This meta operation can be used to print basic information (name, version,
    source/output roots, etc) for one or more projects.

  * New update-for-{test,install} operation aliases.

  * Support for forwarded configurations with target backlinking. See the
    configure meta-operation discussion in b(1) for details.

  * Improvements to the in module (in.symbol, in.mode={strict|lax}).

  * New $directory(), $base(), $leaf() and $extension() path functions.

  * New $regex.split(), $regex.merge() and $regex.apply() functions.

  * Support for (parallel) bootstrapping using GNU make makefile.

  * Support for chroot'ed install (aka DESTDIR):

    b config.install.root=/usr config.install.chroot=/tmp/install

  * Support for prerequisite-specific variables, used for the bin.whole
    variable ("link whole archive").

  * Regularize directory target/scope-specific variable assignment syntax:

    $out_root/: foo = bar # target
    $out_root/  foo = bar # scope
    $out_root/
    {
      foo = bar           # scope
    }

  * Support for structured result output (--structured-result).

  * Support for build hooks.

    The following buildfiles are loaded (if present) at appropriate times from
    the out_root subdirectories of a project:

    build/bootstrap/pre-*.build   # before loading bootstrap.build
    build/bootstrap/post-*.build  # after  loading bootstrap.build
    build/root/pre-*.build        # before loading root.build
    build/root/post-*.build       # after  loading root.build

  * New run directive.

    Now it is possible to:

    run echo 'foo = bar'
    print $foo

  * New dump directive.

    It can be used to print (to stderr) a human-readable representation of the
    current scope or a list of targets. For example:

    dump                           # Dump current scope.
    dump lib{foo} details/exe{bar} # Dump two targets.

    This is primarily useful for debugging as well as to write build system
    tests.

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 library 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}

    # 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 the 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 well as 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 <expression> [<description>]
    assert! <expression> [<description>]

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

Version 0.2.0

  * First public release.