[build2] build2 0.14.0 released

Boris Kolpackov boris at codesynthesis.com
Mon Oct 25 10:31:07 UTC 2021


Matthew Krupcale via users <users at build2.org> writes:

> On Tue, Oct 19, 2021 at 7:50 AM Boris Kolpackov via users <users at build2.org> wrote:
> >
> > We have released build2 toolchain version 0.14.0.
> 
> Congratulations on the new release!

Thanks!


> >   * Support for hermetic build configurations.
> >
> 
> I see that this says that it may be extended in the future to disallow
> changing external resources like compilers, system headers, and
> libraries. Does "disallow" mean a compiler change will not build at
> all, or this new compiler configuration will rebuild hermetically?

Yes, the idea is to detect the change and fail to build.


> If the former, then one should use config.config.hermetic.reload=true
> to allow the compiler change to build?

Right.


> And if the latter, how does this differ from the current behavior
> where the compiler e.g. --version output change would be detected
> already and thus rebuild (albeit non-hermetically)?

Yes, it would not differ. Currently we detect such changes and
rebuild automatically.


> >   * Initial Emscripten compiler support.
> 
> Cool, are there plans to support the LLVM implementation for the
> wasm32-wasi target? I don't have much experience with WASM, but when I
> did a little with it, I found it annoying needing to use/get the
> emscripten compiler.

There are no immediate plans but that can change if there is interest
and someone willing to do the legwork.


> >   * Consistently install prerequisites from any scope by default.
> >
> >     It is also now possible to adjust this behavior with the global
> >     !config.install.scope override. Valid values for this variable are:
> >
> >     project -- only from project
> >     bundle  -- from bundle amalgamation
> >     strong  -- from strong amalgamation
> >     weak    -- from weak amalgamation
> >     global  -- from all projects (default)
> 
> I think this may be a change that's causing a failure in my previous
> bootstrap sequence as I'm trying to update to v0.14.0 for Fedora. In
> particular, this is what I do:
> 
> [...]
> 
> # add !config.install.scope to try to avoid installing libodb
> build2-0.14.0/build2/b-boot install: '!config.install.scope=project'
> build2-0.14.0/libbutl-0.14.0/ build2-0.14.0/ libbpkg-0.14.0/
> bpkg-0.14.0/ bdep-0.14.0/
> error: incompatible libodb-2.5.0-b.21/odb/liba{odb} build
>   info: library is built not for install
>   info: while updating (for install) bpkg-0.14.0/bpkg/exe{bpkg}
>   info: while updating (for install) bpkg-0.14.0/bpkg/exe{bpkg}
>   info: while updating (for install) bpkg-0.14.0/dir{bpkg/}
>   info: while updating (for install) dir{bpkg-0.14.0/}
> 
> What should I do in this case since I don't want to install the static
> libodb libraries? config.install=false was the previous mechanism in
> this case. Is there an equivalent way to achieve this result?

I believe the last error is due to additional consistency checking that
we've added in 0.14.0. In other words, the issue was always there, we
just didn't detect it.

I am not sure what you mean by config.install=false here but I think
the straightforward solution would be to not build liba{}'s if you don't
want to install them. Try adding '!config.bin.lib=shared' to the above
command.


> >   * New file cache for intermediate build results.
> >
> >     The file cache is used to store intermediate build results, for example,
> >     partially-preprocessed C/C++ translation units (those .i/.ii files). The
> >     cache implementation to use is controlled by the new --file-cache option.
> >     Its valid values are noop (no caching or compression) and sync-lz4 (no
> >     caching with synchronous LZ4 on-disk compression; this is the default).
> 
> Is this a typo, or is the caching functionality not enabled yet? That
> is, intermediate results are compressed but not cached yet?

Correct. The caching infrastructure is there but there are no "backends"
yet that implements it. Synchronous LZ4 on-disk compression turned out
to be so good that we didn't bother with async and/or caching for now.



More information about the users mailing list