[build2] build2 0.12.0 released
Boris Kolpackov
boris at codesynthesis.com
Wed Nov 20 12:36:41 UTC 2019
We have released build2 toolchain version 0.12.0. The main objective of this
release was support for build system modules and it took a while to tie up all
the loose ends in this area. As a result, this release has accumulated quite a
large number of other major new features across the toolchain.
A note on backwards compatibility: in this release the build system saw a
major reorganization (discussed below). As a result, this release cannot be
upgraded to from 0.11.0 and has to be installed from scratch.
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.12.0.xhtml
In other news, we now have the Contributing section on our Community page:
https://build2.org/community.xhtml#contribute
As well as the Project Roadmap:
https://github.com/build2/README/blob/master/roadmap.md
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 staged snapshots.
Note that all the install scripts and batch files now support the --local
option to skip building the final version from packages and instead build it
from the build2-toolchain archive directly. In particular, this can be used
for offline installation.
The following new build configurations have been added to the CI service:
linux_debian_10-gcc_9.2
linux_debian_10-clang_9.0
linux_debian_10-clang_9.0_libc++
macos_10.15-clang_11.0
macos_10.15-gcc_9.2_homebrew
freebsd_12-clang_8.0
windows_10-msvc_16.3
windows_10-clang_8.0_msvc_16.3
windows_10-clang_9.0_msvc_16.3
windows_10-clang_9.0_msvc_16.3_lld
For the complete list of available build configurations see:
https://ci.cppget.org/?build-configs
Installation instructions:
https://build2.org/install.xhtml
Download directory:
https://download.build2.org/0.12.0/
SHA256 checksums:
da35b527aac3427b449ca7525e97f81faba776ae7680179521963b90a21fba12 *build2-install-0.12.0.sh
f3eedb06b13fc74d5cac762a6c73e43f232815724e816176bfed51862296ba77 *build2-install-clang-0.12.0.bat
19bdf0b1b33e86cae11fb18cb0b03559bf3f0e0289dbb96af5bcdd325411398e *build2-install-msvc-0.12.0.bat
2e20744621478fd2d96e29df70721587996dfa647a03def567b82b619788f46c *build2-install-mingw-0.12.0.bat
a0ecf9930b873242a0164653411caca2cc5c095abda5ee7bda800f1b0f93e396 *build2-toolchain-0.12.0.tar.xz
1de1e1740a5359295262b21209d0372e0958d7c6cd50863c9697b56aac65f10a *build2-toolchain-0.12.0.tar.gz
b998d0278a532220a6af156db900209e294135658caf6813db42254e3dbfe475 *build2-baseutils-0.12.0-x86_64-windows.zip
fd88a17f4dd498bc2d7958e141fcaca7e6d6b106d779a6a24cdb0160f91c8177 *build2-mingw-0.12.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.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 at 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{*}
bdep version 0.12.0
* Support for creating new projects with existing files.
The bdep-new command now also recognizes and handles the following
existing filesystem entries in the project root:
.git -- assume VCS is already initialized and is Git
LICENSE -- try to guess the manifest license from contents
README.md -- try to extract the manifest summary line from contents
Overall, the idea is to streamline the workflow where one creates a
project on one of the hosting services (GitHub, GitLab, etc) and then
initializes it with bdep-new.
Also, to this effect, specifying the project name is now optional and if
omitted, the current working directory (or --output-dir, if specified) is
assumed to be the project name.
An example of this streamlined workflow:
$ # create project with LICENSE and README.md on a Git hosting service
$ git clone .../libhello.git
$ cd libhello
$ bdep new -t lib
Finally, with this change it now makes sense to have support for pre-
creation hooks (--pre-hook) in addition to post-creation (--post-hook).
* Support for default options files (aka tool config files).
See the bdep-default-options-files(1) help topic for background and the
DEFAULT OPTIONS FILES section in each command's man pages for specifics.
* New bdep-new no-install project type sub-option.
In particular, this should be useful when creating *-tests packages.
* The C library projects created by bdep-new are now portable.
Specifically, the use of fmemopen() was replaced with tmpfile().
* The pre and post-creation hooks now make use of portable builtins.
To instead use a system-provided program, prefix the name with `^`, for
example:
$ bdep new --post-hook "^cat --squeeze-blank .../.gitignore >>.gitignore"
See bdep-new(1) for details.
* Ability to specify <pkg-args> in the bdep-init command's -A and -C forms.
* Ability to keep/update/remove the current tag in the bdep-release
command's revision mode.
Note also that previously the default was to update while now it is to
keep.
* Ability to have multiple forwarded configurations.
The new constraint is that such configurations should not have any common
packages (a package's source directory cannot be forwarded to multiple
configurations).
* New bdep-submit --forward option.
This option instructs bdep-submit to use each package's forwarded
configuration in order to prepare the distributions. This helps with
setups where there is no single configuration that has all the packages
(such as a build system module project).
* New bdep-init --no-sync option.
This allows postponing initialization in the build configurations to a
later explicit bdep-sync. One subtle difference with such an explicit sync
is that it will be performed without having the project's database open,
which can be important if the initialization triggers an implicit sync
(via a hook) of a project that uses the same database (as is the case with
build system module projects).
bpkg version 0.12.0
* Ability to specify the full package version constraint in the pkg-build
command.
For example:
$ bpkg build "bar < 2.0.0"
See bpkg-pkg-build(1) for details.
* Support for default options files (aka tool config files).
See the bpkg-default-options-files(1) help topic for background and the
DEFAULT OPTIONS FILES section in each command's man pages for specifics.
* Support for tests, examples, and benchmarks as separate packages.
See the "tests, examples, benchmarks" section in the manual for details.
brep version 0.12.0
* Support for specifying explicit environment names in buildtabs.
* Support for tests, examples, and benchmarks as separate packages.
* The submit-git handler can now replace an existing package version
revision.
* Significant speedup to the builds page loading.
* Unbuilt configurations are now displayed on the package version details
page.
* Support for marking internal repositories as non-buildable.
More information about the users
mailing list