[build2] build2 toolchain 0.4.0 released
Boris Kolpackov
boris at codesynthesis.com
Wed Sep 7 12:28:34 UTC 2016
Hi,
We have released build2 toolchain 0.4.0. It includes a large number of new
features in the build system, package manager, and repository web interface.
Note also that this is still an alpha release that is more of a technology
preview rather than anything that is ready for production. It has been
tested on Windows, Linux, Mac OS, and FreeBSD with GCC, Clang (both vanilla
and Apple's), MinGW GCC, MSVC, and Intel icc.
The corresponding NEWS file entries are included below. A more detailed
discussion of the major new features is available in the release notes:
https://build2.org/release/0.4.0.xhtml
Note that this release is backwards-incompatible with 0.3.0 and cannot be
upgraded to with the package manager. Furthermore, the config.build format
has changed as well so you will have to reconfigure any existing projects
you might have.
Download and build instructions:
https://build2.org/download.xhtml
Download directory:
https://download.build2.org/0.4/
SHA256 checksums:
75605cb77b53401393fc988c65b1f20717b14de43ae5dd6ad94b1e54d1f4b29c *build2-toolchain-0.4.0.tar.gz
ae894a37883ec877bcdf152efb8cbd03d98eb4ffb250728f2b29248d89b787a4 *build2-toolchain-0.4.0.tar.xz
ac653bed3d01197ccd548fd648f0a1290e45f9998187a14cd515db224dcc5d68 *build2-baseutils-0.4.0-i686-windows.zip
058d2eaccd18181f21e4f7da629e057d65d019cff1f35d743680d91fac61c962 *build2-baseutils-0.4.0-x86_64-windows.zip
a1a6869003b41591858cba55d3eed5b9e058a69a7d4f5385ccb1c11e7e1e053a *build2-mingw-0.4.0-i686-windows.tar.xz
e723fe54fb6fcbdbd88c2453ce6b750977ef568d71efc359c2fc49de1a7bc305 *build2-mingw-0.4.0-x86_64-windows.tar.xz
Note that the cppget.org repository that hosts the individual packages
is now signed. Its certificate details and the SHA256 fingerprint are:
CN=cppget.org/O=Code Synthesis/admin at 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.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 at 1.2.3 freebsd at 1.2 windows at 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{}.
bpkg version 0.4.0
* Support for repository signing and authentication.
The rep-create command can now sign the repository with rep-fetch(fetch)
and rep-info authenticating it. See the bpkg-repository-signing(1) help
topic for details.
* Support for system packages.
Now a package can be "built" as available from the system rather than
compiling it from source. To specify a system package the new sys: package
scheme is used, for example:
bpkg build sys:libsqlite3
Currently, if no version is specified for a system package, then it is
considered to be unknown but satisfying any dependency constraint (such a
wildcard version is displayed as '*'). In the future bpkg will support
querying system package managers (rpm, dpkg, pkg-config) for the installed
version.
See the pkg-build(build) man page for details.
* Support for stub packages.
A stub is a package without source code. It has the special upstream
version 0 (with a possible revision, for example 0+1) and can only be
built as a system package.
* Support for build-time dependencies.
Now a depends: value in the package manifest that starts with '*' is
recognized as a built-time dependency. Currently, build-time dependencies
are treated in the same way as normal (run-time) ones except that the
'build2' and 'bpkg' names are recognized as special. They can be used to
specify a constraint (usually the required minimum version) on the build2
build system and package manager, respectively. In the future, the
semantics for build-time dependencies will be extended, for example, to
verify that they can be executed on the build machine and/or to build them
in a separate configuration in case of cross-compilation.
* The pkg-build(build) command now offers to automatically update dependent
packages that were reconfigured.
It also supports the following new options:
--drop-prerequisite|-D
--update-dependent|-U
--leave-dependent|-L
As well as the -K alias for --keep-prerequisite. See the command's man
page for details.
* The pkg-drop(drop) command now supports the following new options:
--keep-dependent|-K,
--drop-prerequisite|-D
--keep-prerequisite
See the command's man page for details.
* The cfg-add command was renamed to rep-add (the add alias stays the same)
and cfg-fetch to rep-fetch (the fetch alias stays the same).
* The new -V option is an alias for --verbose 3 (show all commands).
brep version 0.4.0
* Support for signed repositories.
The repository certificate information (subject, fingerprint) and the
certificate itself are now displayed on the repository about page.
* Support for displaying stub packages, build-time dependencies.
* All the brep prerequisites except the Apache2 headers are now available as
build2 packages. This significantly simplifies building. See the INSTALL
file for details.
Enjoy,
Boris
More information about the users
mailing list