[build2-announce] build2 0.13.0 released
Boris Kolpackov
boris at codesynthesis.com
Mon Jul 20 14:15:43 UTC 2020
We have released build2 toolchain version 0.13.0. The main focus of this
release is build system support for project-specific configurations and
ad hoc recipes. Another notable new feature is support for the creation
of alternative (e.g., with include/src split) source code layouts by the
bdep-new command. We have also switched to the SPDX License Expression
as the default license name scheme (old names in existing packages will
still work).
A note on backwards compatibility: this release cannot be upgraded to from
0.12.0 and has to be installed from scratch. Additionally, on UNIX-like
operating systems the installation script now installs the toolchain
libraries into a private subdirectory of lib/. This means that when
installed into a shared location such as /usr/local/, the toolchain
implementation details can no longer clash with anything that is already
installed or might be installed in the future into the same location by
the user.
The corresponding NEWS file entries are included below with a more detailed
discussion of the major new features available in the release notes:
https://build2.org/release/0.13.0.xhtml
This release has been tested on Windows, Linux, Mac OS, and FreeBSD with
GCC, Clang (both vanilla and Apple's), MinGW GCC, and MSVC (14, 15, and
16). A big thank you to everyone who helped test the release candidate.
There is also now:
- Experimental support for NetBSD.
- Gentoo ebuild file: https://packages.gentoo.org/packages/dev-util/build2
The following new build configurations have been added to the CI service:
linux_debian_9-gcc_8.4
linux_debian_10-gcc_9.3
linux_debian_10-gcc_10.1
linux_debian_10-clang_10.0[_libc++]
macos_10.15-clang_11.0 (Xcode 11.5 Clang 11.0.3)
macos_10.15-gcc_9.3_homebrew
windows_10-msvc_16.4
windows_10-msvc_16.5
windows_10-msvc_16.6
windows_10-clang_10.0_llvm_msvc_16.6[_lld]
windows_10-gcc_9.2_mingw_w64
In addition, there are now optimized and static optimized builds for the
latest version of every configuration. All in all, there are now 57 build
configurations, up from 42 in the previous release. For the complete list,
see:
https://ci.cppget.org/?build-configs
Installation instructions:
https://build2.org/install.xhtml
Download directory:
https://download.build2.org/0.13.0/
SHA256 checksums:
aeec2ac0e7080341159bbbc95d8264521ddf82bda01c5c253d63cae5b4558b15 *build2-install-0.13.0.sh
bb20552ef26862ee9101c9e5f1677ddae911798bafc259b1ef06f64ba29ab163 *build2-install-msvc-0.13.0.bat
a8c08441c82b9601e61634933fa1bfe1ef08f0d4e22e51b34d50a33ad81f0163 *build2-install-clang-0.13.0.bat
60f36c7f5135676d0772dd67ccfac012b8bcb9e9177c9305a889fd54782b6870 *build2-install-mingw-0.13.0.bat
bafabcab4d5efdc489af59755a3ba7ce90834b479125cf21c34828857cc91506 *build2-toolchain-0.13.0.tar.xz
4be9fdd0c9511bd9ecf8399c4bc2eac46bd01e637e86ad0b76d7db482f4e5b11 *build2-toolchain-0.13.0.tar.gz
4382174132e1dc7ca79d7ab2d1406d14afbfc927b9814fe7e7285781eabc3022 *build2-baseutils-0.13.0-x86_64-windows.zip
00345f8e0ac5e93c9e2bee8cd6127fc922528a99ed4a543d7baa28a3a60b13e6 *build2-mingw-0.13.0-x86_64-windows.tar.xz
Repository certificate fingerprint for cppget.org:
86:BA:D4:DE:2C:87:1A:EE:38:C7:F1:64:7F:65:77:02:15:79:F3:C4:83:C0:AB:5A:EA:F4:F7:8C:1D:63:30:C6
NEWS file entries:
build2 version 0.13.0
* Support for project-specific configuration.
A project can now use the config directive to define config.<project>.*
variables, similar to the build system core and modules. For example:
config [bool] config.libhello.fancy ?= false
config [string] config.libhello.greeting ?= 'Hello'
These variables can then be used in buildfiles and/or propagated to the
source code using the command line, .in file substitution, etc. For
example:
if $config.libhello.fancy
cxx.poptions += -DLIBHELLO_FANCY
cxx.poptions += "-DLIBHELLO_GREETING=\"$config.libhello.greeting\""
See the "Project Configuration" chapter in the manual for details.
* Support for ad hoc recipes.
With ad hoc recipes it is now possible to provide custom implementations
of operations (update, test, etc) for certain targets. For example, this
is how we can pick a config header based on the platform:
hxx{config}: hxx{config-linux}: include = ($cxx.target.class == 'linux')
hxx{config}: hxx{config-win32}: include = ($cxx.target.class == 'windows')
hxx{config}: hxx{config-macos}: include = ($cxx.target.class == 'macos')
hxx{config}:
{{
cp $path($<) $path($>)
}}
Another, more elaborate example that shows how to embed binary data into
the source code with the help of the xxd(1) utility:
import! xxd = xxd%exe{xxd}
<{hxx cxx}{foo}>: file{foo.bin} $xxd
{{
diag xxd ($<[0])
i = $path($<[0]) # Input.
h = $path($>[0]) # Output header.
s = $path($>[1]) # Output source.
n = $name($<[0]) # Array name.
# Get the position of the last byte (in hex).
#
$xxd -s -1 -l 1 $i | sed -n -e 's/^([0-9]+):.*$/\1/p' - | set pos
if ($empty($pos))
exit "unable to extract input size from xxd output"
end
# Write header and source.
#
echo "#pragma once" >$h
echo "extern const char $n[0x$pos + 1];" >>$h
echo "extern const char $n[0x$pos + 1]= {" >$s
$xxd -i <$i >>$s
echo '};' >>$s
}}
Note that in both examples, the utilities (cp, echo, and sed) are builtins
which means these recipes are portable. See the Testscript manual for the
list of available builtins.
Ad hoc recipes can also be used to customize a part of the update chain
otherwise handled by rules. For example, in embedded systems development
it is often required to perform a custom link step:
obje{foo}: cxx{foo}
obje{bar}: cxx{bar}
<exe{test} file{test.map}>: obje{foo bar}
{{
diag ld ($>[0])
$cxx.path $cc.loptions $cxx.loptions $cxx.mode -o $path($>[0]) \
"-Wl,-Map=$path($>[1])" $path($<) $cxx.libs $cc.libs
}}
While the above examples are all for the update operation, ad hoc recipes
can be used for other operations, such as test. For example:
exe{hello}: cxx{hello}
% test
{{
diag test $>
$> 'World' >>>?'Hello, World!'
}}
The above recipes are written in a shell-like language called Buildscript
that has similar semantics to Testscript tests. Another language that can
be used to write recipes is C++. For example:
./:
{{ c++ 1
recipe
apply (action, target& t) const override
{
text (recipe_loc) << "Hello, " << t;
return noop_recipe;
}
}}
Note that in this release support for ad hoc recipes is at the "technology
preview" stage. In particular, there is no documentation and there might
be some rough edges.
* Support for project-local importation.
An import without a project name is now treated as importation from the
same project. For example, given the libhello project that exports the
lib{hello} target, a buildfile for an executable in the same project
instead of doing something like this:
include ../libhello/
exe{hello}: ../libhello/lib{hello}
Can now do:
import lib = lib{hello}
exe{hello}: $lib
Note that the target in project-local importation must still be exported
in the project's export stub. In other words, project-local importation
goes through the same mechanism as normal import.
See the "Target Importation" section in the manual for details.
* Support for ad hoc importation and "glue buildfiles".
If the target being imported has no project name and is either absolute or
is a relative directory, then this is treated as ad hoc importation.
Semantically it is similar to normal importation but with the location of
the project being imported hard-coded into the buildfile.
In particular, this type of import can be used to create a special "glue
buildfile" that "pulls" together several projects, usually for convenience
of development. One typical case that calls for such a glue buildfile is a
multi-package project. To be able to invoke the build system directly in
the project root, we can add a glue buildfile that imports and builds all
the packages:
import pkgs = */
./: $pkgs
See the "Target Importation" section in the manual for details.
* Support for value subscripts.
A value subscript is only recognized in evaluation contexts (due to
ambiguity with wildcard patterns; consider: $x[123].txt) and should be
unseparated from the previous token. For example:
x = ($y[1])
x = (($f ? $y : $z)[1])
x = ($identity($y)[$z])
* New legal{} target type and config.install.legal variable.
This allows separation of legal files (LICENSE, AUTHORS, etc) from other
documentation. For example:
./: ... doc{README} legal{LICENSE}
$ b install ... config.install.legal='share/licenses/<project>/'
* Support for <var>-substitutions in config.install.* values.
The currently recognized variable names are <project> and <private> which
are replaced with the project name and private subdirectory, respectively.
This can be used along these lines:
$ b config.install.libexec='exec_root/lib/<project>/' install
The private installation subdirectory can be used to hide the
implementation details of a project. This is primarily useful when
installing an executable that depends on a bunch of libraries into a
shared location, such as /usr/local/. For example:
$ b config.install.private=foo install
See the "Install Module" chapter in the manual for details.
* New $regex.find_{match,search}() functions that operate on lists.
* The $process.run*() functions now recognize a number of portable builtins.
Refer to the Testscript manual for the list and details.
* New $defined(<variable>) and $visibility(<variable>) functions.
* New $target.process_path() function for exe{} targets analogous to
$target.path().
* New $bin.link_member() function.
Given a linker output target type (exe, lib[as], or libu[eas]) this
function returns the target type of the lib{} group member (liba or libs)
that will be picked when linking a lib{} group to this target type.
* New scripting builtins: date, env.
Refer to the Testscript manual for details.
* New variable block applicability semantics in dependency chains.
Previously the block used to apply to the set of prerequisites before the
last colon. This turned out to be counterintuitive and not very useful
since prerequisite-specific variables are less common than target-
specific ones.
The new rule is as follows: if the chain ends with a colon, then the block
applies to the last set of prerequisites. Otherwise, it applies to the
last set of targets. For example:
./: exe{test}: cxx{main}
{
test = true # Applies to the exe{test} target.
}
./: exe{test}: libue{test}:
{
bin.whole = false # Applies to the libue{test} prerequisite.
}
* Test and install modules are now implicitly loaded for simple projects.
While these can be useful on their own, this also makes the test and
install operations available in simple projects, which is handy for "glue
buildfiles" that "pull" (using ad hoc import) a bunch of other projects
together.
* The translated {c,cxx}.std options are now folded into the compiler mode
options ({c,cxx}.mode).
This makes them accessible from ad hoc recipes. The original mode/path are
available in {c,cxx}.config.mode/path.
* Generation of a common pkg-config .pc file in addition to static/shared-
specific.
The common .pc file is produced by ignoring any static/shared-specific
poptions and splitting loptions/libs into Libs/Libs.private.
It is "best effort", in a sense that it's not guaranteed to be sufficient
in all cases, but it will probably cover the majority of cases, even on
Windows, thanks to automatic dllimport'ing of functions.
* The ~host configuration now only contains the cc and bin modules
configuration.
There is also the new ~build2 configuration that contains everything
(except config.dist.*) and is meant to be used for build system modules.
* Reworked tool importation support.
Specifically, now config.<tool> (like config.cli) is handled by the import
machinery (it is a shorter alias for config.import.<tool>.<tool>.exe that
we already had).
This also adds support for uniform tool metadata extraction that is
handled by the import machinery. As a result, a tool that follows the
"build2 way" can be imported with metadata by the buildfile and/or
corresponding module without any tool-specific code or brittleness
associated with parsing --version or similar outputs. See the cli
tool/module for an example of how this all fits together.
Finally, two new flavors of the import directive are now supported:
import! triggers immediate importation skipping any rule-specific logic
while import? is optional import (analogous to using?). Note that optional
import is always immediate. There is also the import-specific metadata
attribute which can be specified for these two import flavors in order to
trigger metadata importation. For example:
import? [metadata] cli = cli%exe{cli}
if ($cli != [null])
info "cli version $($cli:cli.version)"
* Backtick (`) and bit-or (|) are reserved in eval context for future use.
Specifically, they are reserved for planned support of arithmetic eval
contexts and evaluation pipelines, respectively.
bpkg version 0.13.0
* The SPDX License Expression is now the default scheme for the 'license'
package manifest value.
See the "license" section in the manual for details.
* New --pkg-proxy common option.
This option specifies the proxy server to use when fetching package
manifests and archives from remote pkg repositories. See the option
documentation in bpkg-common(1) for details.
* External test packages can now have their own build constraints.
bdep version 0.13.0
* The SPDX License Expression in now the default scheme in the bdep-new
--type|-t,license sub-option.
Auto-detected licenses now also result in the SPDX License ID in the
'license' package manifest value.
* New source layout customization mechanisms in bdep-new.
In particular, the split include/src layout is now supported out of the
box:
$ bdep new -l c++ -t lib,split libhello
See the SOURCE LAYOUT section in bdep-new(1) for details and a large
number of examples.
* The bdep-new command in the --package mode now creates the "glue
buildfile" for the project.
* The bdep-new command now generates the .gitattributes file with sensible
defaults.
* The bdep-new --subdirectory mode option has been renamed to --source.
The corresponding default options file has also been renamed to
bdep-new-source.options.
* The bdep-new binless sub-option has been moved from --lang|-l to --type|t.
brep version 0.13.0
* Support for the alternative package rebuild timeout.
The alternative rebuild timeout can be used to "pull" the rebuild window
to the specified time of day, for example, to optimize load and/or power
consumption of the build infrastructure (off-work hours, solar, off-peak
electricity tariffs, etc).
* New brep-monitor utility for monitoring for and reporting on brep state
issues. Currently it only reports build delays. See brep-monitor(1) for
details.
* Support for test-exclude task manifest value.
bbot version 0.13.0
* Build logs are now UTF-8-sanitized by the worker.
* Support for test-exclude task manifest value.
* Bootstrap timeout has been increased from 30 to 60 minutes.
More information about the announce
mailing list