build2/0.16.0-a.0.20230124113841.53d082d06f4d

build2 build system

This package contains the build2 build system.

build2 is an open source, cross-platform toolchain for building and packaging
C++ code. Its aim is a modern build system and dependency manager for the C++
language that provide a consistent, out of the box interface across multiple
platforms and compilers. For more information see:

https://build2.org/

See the NEWS file for the user-visible changes from the previous release.

See the LICENSE file for the distribution conditions.

See the INSTALL file... More

Depends (2)

Requires (1)

Builds

Changes

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.

  * 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 forms of print_diag()):

    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 GH issue #40 for additional background/details.

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

    The original name is still recognized for backwards compatibility.

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

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