[build2] build2 0.11.0 released
Alex Syrnikov
san at masterspline.eu
Tue Jun 11 15:00:14 UTC 2019
What is brep and how to build it?
On 11.06.2019 11:42, Boris Kolpackov wrote:
> We have released build2 toolchain version 0.11.0. This release contains a
> large number of new features across all the tools (build system, dependency
> managers, etc). It also includes experimental support for C++ modules header
> unit importation and include translation.
>
> A note on backwards compatibility: in this release we have extended the
> numeric representation of the standard versioning scheme. As a result,
> this release cannot be upgraded to from 0.10.0 and has to be installed
> from scratch. Additionally, while existing libraries created with bdep-new
> will continue to work, the comment that describes the versioning scheme in
> version.hxx.in (or equivalent) will no longer be accurate. The easiest way
> to fix this is to run bdep-new on the side to create an identically-named
> project and copy the new version.hxx.in over.
>
> 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.11.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 staged snapshots.
>
> The following new build configurations have been added to the CI service:
>
> linux_debian_9-gcc_9.1
> linux_debian_9-clang_8.0
>
> macos_10.14-clang_10.0
> macos_10.14-gcc_9.1_homebrew
>
> windows_10-msvc_16.1
>
> 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.11.0/
>
> SHA256 checksums:
>
> 37396ed937f94cf02d51c6b9f21c8cc0f95384a6325059eb24a5eba0affcd504 *build2-install-0.11.0.sh
> 3aa16ba0aae052ec59c622a29db9fb4834ac9bda188094ace6e193ce6aff91cb *build2-install-msvc-0.11.0.bat
> 213a829f12917a6febee42740f7804f1fc687f374b983e640afd75c479b11c37 *build2-install-mingw-0.11.0.bat
>
> 653bb75f31ca05760eba62bb6727d11a9f0d8ce4aa2fc1fb996d7ef6e76a4938 *build2-toolchain-0.11.0.tar.xz
> c0232481826d9881bed1d29b4a75e56cb8ce12b3c37b2b34b24e0a59a1d1b271 *build2-toolchain-0.11.0.tar.gz
>
> 2353dae2b39706a4a80dbf2e5e28c99355b753f3986256c1c9a7e99485d1a70b *build2-baseutils-0.11.0-x86_64-windows.zip
> 65e3becc2edf7989d78569a72d030a88467fc5fb9c7b262d0d1f4575479c040c *build2-mingw-0.11.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.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.
>
>
> bdep version 0.11.0
>
> * The bdep-new command now by default adds a README.md template. This can be
> suppressed with the new no-readme project type sub-option. For example:
>
> $ bdep new -t exe,no-readme hello
>
> * New license=<name> bdep-new project type sub-option allows specifying a
> project license. For example:
>
> $ bdep new -t exe,license=MIT hello
>
> Commonly used license names are 'MIT', 'ASLv2' (Apache License 2.0),
> 'GPLv3', and 'proprietary' (see the 'license' package manifest value
> documentation for a more extensive list of names). Note that if the
> license is not specified, the default is now 'proprietary' instead of
> 'TODO'.
>
> * New bdep-new --post-hook option allows the execution of customization
> commands in the newly created project. For example:
>
> $ bdep new --post-hook "echo .idea/ >>.gitignore" hello
>
> See the bdep-new(1) man pages for details.
>
> * The bdep-ci command now allows overriding certain manifest values in
> packages being submitted for testing. This is primarily useful for
> specifying alternative build configurations and/or build notification
> emails. For example:
>
> $ bdep ci --builds gcc
>
> See the bdep-ci(1) man pages for details.
>
> * New bdep-release --amend and --squash options allow releasing a revision
> by squashing and amending one or more existing commits.
>
> * New --existing|-e option for bdep-{init,new} --config-create|-C and
> bdep-config create modes. With this option bdep initializes a bpkg
> configuration based on an existing build system configuration instead of
> creating a new one from scratch. For example:
>
> $ b create: build-clang/,cc config.cxx=clang++
> $ bdep new -C build-clang --existing hello
>
>
> bpkg version 0.11.0
>
> * The 'tags' package manifest value has been deprecated and replaced with
> 'keywords' (list of space-separated words) and 'topics' (list of comma-
> separated, potentially multi-word concepts). For example:
>
> topics: xml parser, xml serializer
> keywords: sax dom
>
> * New 'description-type' package manifest value allows specifying the
> content type of the 'description' or 'description-file' value. Currently,
> recognized values are:
>
> text/plain
> text/markdown
> text/markdown;variant=GFM
> text/markdown;variant=CommonMark
>
> * New 'upstream-version' package manifest value allows preserving the
> original version for information.
>
> * The pkg-build command can now "build" a system package that doesn't have a
> stub provided its version is specified explicitly. For example:
>
> $ bpkg build ... ?sys:libsqlite3/* ?sys:libcurl/7.47.0
>
> * New cfg-create --existing|-e option allows initializing a bpkg
> configuration based on an existing build system configuration instead of
> creating a new one from scratch. For example:
>
> $ b create: build-clang/,cc config.cxx=clang++
> $ bpkg create -d build-clang --existing
>
> * New rep-info --deep option triggers the replacement of '*-file' package
> manifest values with the contents of the referenced files.
>
>
> brep version 0.11.0
>
> * Support for displaying Markdown package descriptions.
>
> * Support for displaying new package manifest values: 'upstream-version',
> 'topics', and 'keywords.
>
> * Various page style cleanups and improvements.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.build2.org/archives/users/attachments/20190611/8a1e25fb/attachment.sig>
More information about the users
mailing list