[Release] Boost 1.70.0 Beta 1 Release Candidate 2
A new release candidates for the first 1.70.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.70.0.beta1.rc2/source/ Changes since the last RC: * The Jamfile for Boost.Predef has been updated to allow running the tests from /status. Thanks to mike.dev@gmx.de for the report, and to Rene for the fix. The release notes are not yet available. The SHA256 checksums are as follows: 26dba8156ad08041c6da52c84a2654aefda292180afe3546a9a74dda0dfb3781 ./boost_1_70_0_b1_rc2.7z ee794d98429bc2bfae054f2fab6fde53ea95f7c5967d8b267e57c894a4d46e57 ./boost_1_70_0_b1_rc2.tar.bz2 bca5f189d87b26ab903838dee2fd4c54e9043bd35d27b8923cdef42651ae7261 ./boost_1_70_0_b1_rc2.tar.gz 6c8f3af4e64d3a04a3d3a5e98499d2f6bb460ad82c1f33ff7da800b5ab182b0b ./boost_1_70_0_b1_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers
On Sat, Mar 9, 2019 at 10:15 AM Marshall Clow via Boost < boost@lists.boost.org> wrote:
A new release candidates for the first 1.70.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.70.0.beta1.rc2/source/
Changes since the last RC: * The Jamfile for Boost.Predef has been updated to allow running the tests from /status. Thanks to mike.dev@gmx.de for the report, and to Rene for the fix.
The release notes are not yet available.
The SHA256 checksums are as follows:
26dba8156ad08041c6da52c84a2654aefda292180afe3546a9a74dda0dfb3781 ./boost_1_70_0_b1_rc2.7z ee794d98429bc2bfae054f2fab6fde53ea95f7c5967d8b267e57c894a4d46e57 ./boost_1_70_0_b1_rc2.tar.bz2 bca5f189d87b26ab903838dee2fd4c54e9043bd35d27b8923cdef42651ae7261 ./boost_1_70_0_b1_rc2.tar.gz 6c8f3af4e64d3a04a3d3a5e98499d2f6bb460ad82c1f33ff7da800b5ab182b0b ./boost_1_70_0_b1_rc2.zip
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
-- The Boost Release Managers
Looks the same as RC1 for me on Visual Studio. * b2 with a relative prefix (and relative libdir/includedir) doesn't work * Can't create libraries for bzip2 and zlib (showstopper? anyone else seeing this?) Other than that things look good. toolset arch compile Link Execute msvc-10.0 32 X X X msvc-10.0 64 X X X msvc-11.0 32 X X X msvc-11.0 64 X X X msvc-12.0 32 X X X msvc-12.0 64 X X X msvc-14.0 32 X X X msvc-14.0 64 X X X msvc-14.1 32 X X X msvc-14.1 64 X X X Compile means that the b2 command completed without errors Link means that visual studio was able to link a sample executable to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) generated Execute means that the linked program executed without errors. Full build logs can be found here: https://gist.github.com/teeks99/58a2fd2a6a7ed1dfecccd3c61ac2dce4 Tom
Tom Kent wrote:
* Can't create libraries for bzip2 and zlib (showstopper? anyone else seeing this?)
I haven't seen your initial report of this issue (on the users list?) but it's probably caused by this change: https://github.com/boostorg/build/commit/5ad92cd76ff393792f30aa50688c95eff24... Before that, -sZLIB_SOURCE=... on the b2 command line would have worked; after it, only the environment variable ZLIB_SOURCE is consulted.
AMDG On 3/9/19 4:37 PM, Peter Dimov via Boost wrote:
Tom Kent wrote:
* Can't create libraries for bzip2 and zlib (showstopper? anyone else seeing this?)
I haven't seen your initial report of this issue (on the users list?) but it's probably caused by this change:
https://github.com/boostorg/build/commit/5ad92cd76ff393792f30aa50688c95eff24...
Before that, -sZLIB_SOURCE=... on the b2 command line would have worked; after it, only the environment variable ZLIB_SOURCE is consulted.
That's not the problem. os.environ sees -s arguments as well. If you build with --debug-configuration it shows that it's picking up the correct path for zlib. Also, the tests run correctly. It's only install/stage that fails. In Christ, Steven Watanabe
Steven Watanabe wrote:
That's not the problem. os.environ sees -s arguments as well. If you build with --debug-configuration it shows that it's picking up the correct path for zlib. Also, the tests run correctly. It's only install/stage that fails.
Yes, I figured that part out, eventually. I tried to replicate. With C:\boost-git\develop>b2 -sZLIB_SOURCE=c:\projects\zlib-1.2.7 install --with-iostreams --debug-configuration on the current develop, I see zlib being installed: common.copy C:\Boost\lib\libboost_zlib-vc141-mt-gd-x64-1_70.lib Which part doesn't work?
AMDG On 3/9/19 5:02 PM, Peter Dimov via Boost wrote:
<snip> I tried to replicate. With
C:\boost-git\develop>b2 -sZLIB_SOURCE=c:\projects\zlib-1.2.7 install --with-iostreams --debug-configuration
on the current develop, I see zlib being installed:
common.copy C:\Boost\lib\libboost_zlib-vc141-mt-gd-x64-1_70.lib
Which part doesn't work?
It works for me as well. I forgot the `install`. The reason that it works for install and not stage is that package.install has <install-dependencies>on hard-coded. In Christ, Steven Watanabe
Steven Watanabe wrote:
It works for me as well. I forgot the `install`. The reason that it works for install and not stage is that package.install has <install-dependencies>on hard-coded.
So in summary, - it doesn't work for Tom because he changed his scripts to use `stage` because of the other problem; - I need to add <install-dependencies>on to https://github.com/boostorg/boost_install/blob/develop/boost-install.jam#L88... Does this sound correct?
AMDG On 3/9/19 5:35 PM, Peter Dimov via Boost wrote:
Steven Watanabe wrote:
It works for me as well. I forgot the `install`. The reason that it works for install and not stage is that package.install has <install-dependencies>on hard-coded.
So in summary,
- it doesn't work for Tom because he changed his scripts to use `stage` because of the other problem; - I need to add <install-dependencies>on to https://github.com/boostorg/boost_install/blob/develop/boost-install.jam#L88...
That's the quick fix. I bet there's no CMake file for zlib either, though.
Does this sound correct?
In Christ, Steven Watanabe
Steven Watanabe wrote:
- I need to add <install-dependencies>on to https://github.com/boostorg/boost_install/blob/develop/boost-install.jam#L88...
Like this? https://github.com/boostorg/boost_install/commit/5bc0961483e5b95b72032e2c343...
That's the quick fix. I bet there's no CMake file for zlib either, though.
Yes, of course. This only takes care of the regression. If we want to support Iostreams built against our own zlib/bzlip2/zstd/lzma from CMake, we'll have to boost-install them somehow. But that's not something we absolutely need in 1.70 as long as it doesn't regress. And we probably need to think about it a bit more, because putting the responsibility for calling `boost-install boost_zlib` on Iostreams doesn't sound correct. After all, another Boost library may well want to use zlib too. But the less-incorrect answers to this will take us in interesting directions.
AMDG On 3/9/19 5:57 PM, Peter Dimov via Boost wrote:
Steven Watanabe wrote:
- I need to add <install-dependencies>on to > https://github.com/boostorg/boost_install/blob/develop/boost-install.jam#L88...
Like this?
https://github.com/boostorg/boost_install/commit/5bc0961483e5b95b72032e2c343...
That looks about right.
That's the quick fix. I bet there's no CMake file for zlib either, though.
Yes, of course. This only takes care of the regression. If we want to support Iostreams built against our own zlib/bzlip2/zstd/lzma from CMake, we'll have to boost-install them somehow. But that's not something we absolutely need in 1.70 as long as it doesn't regress.
Right. I'm unhappy about having multiple partially overlapping ways of tracking library dependencies, but it's good enough for this release.
And we probably need to think about it a bit more, because putting the responsibility for calling `boost-install boost_zlib` on Iostreams doesn't sound correct. After all, another Boost library may well want to use zlib too. But the less-incorrect answers to this will take us in interesting directions.
I /think/ it will be okay if multiple libraries pass zlib to boost-install. In the long run, it's probably best to generalize boost-install and pull it into Boost.Build. I'm not sure how feasible that is, though. In Christ, Steven Watanabe
Steven Watanabe wrote:
I bet there's no CMake file for zlib either, though.
``` list(APPEND _BOOST_IOSTREAMS_DEPS zlib.1 headers) ``` Yes, find_package(boost_iostreams) isn't going to work, but I wonder about the .1 here. Shouldn't this ``` build-name ?= z ; library-id = [ CALC $(library-id) + 1 ] ; ``` be ``` library-id = [ CALC $(library-id) + 1 ] ; build-name ?= z.$(library-id) ; ``` ? That is, when <build-name> is given explicitly, as it is for Iostreams, do not append a library-id.
AMDG On 3/10/19 6:35 AM, Peter Dimov via Boost wrote:
Steven Watanabe wrote:
I bet there's no CMake file for zlib either, though.
``` list(APPEND _BOOST_IOSTREAMS_DEPS zlib.1 headers) ```
Yes, find_package(boost_iostreams) isn't going to work, but I wonder about the .1 here. Shouldn't this
``` build-name ?= z ; library-id = [ CALC $(library-id) + 1 ] ; ```
be
``` library-id = [ CALC $(library-id) + 1 ] ; build-name ?= z.$(library-id) ; ```
?
That is, when <build-name> is given explicitly, as it is for Iostreams, do not append a library-id.
You need to strip suffixes. The library id only affects the internal Boost.Build target name, not the file names. In Christ, Steven Watanabe
Steven Watanabe wrote:
list(APPEND _BOOST_IOSTREAMS_DEPS zlib.1 headers) ...
You need to strip suffixes. The library id only affects the internal Boost.Build target name, not the file names.
I'm not sure about that. The purpose of that incrementing library-id, as far as I can infer, is to enable two libraries to have their own private zlib dependencies. But since it's not reflected in the file names, trying to stage or install the two libraries will still fail unless they use distinct <build-name>s. And if they use distinct <build-name>s, there's no need to append a library-id to them.
AMDG On 3/10/19 9:09 AM, Peter Dimov via Boost wrote:
Steven Watanabe wrote:
list(APPEND _BOOST_IOSTREAMS_DEPS zlib.1 headers) ...
You need to strip suffixes. The library id only affects the internal Boost.Build target name, not the file names.
I'm not sure about that.
The purpose of that incrementing library-id, as far as I can infer, is to enable two libraries to have their own private zlib dependencies.
That's not really correct. The reason for the library-id is to make sure that target alternative selection only happens at the top level on the /zlib//zlib target. After reviewing the code again, I don't think library-id is needed for the current version (Although removing the library-id will cause a failure in the corner case of <build-name>zlib). IIRC, an earlier version of zlib.jam had separate arguments for the condition (applied to /zlib//zlib) and requirements (applied to the actual library target).
But since it's not reflected in the file names, trying to stage or install the two libraries will still fail unless they use distinct <build-name>s. And if they use distinct <build-name>s, there's no need to append a library-id to them.
In Christ, Steven Watanabe
Steven Watanabe wrote:
The purpose of that incrementing library-id, as far as I can infer, is to enable two libraries to have their own private zlib dependencies.
That's not really correct. The reason for the library-id is to make sure that target alternative selection only happens at the top level on the /zlib//zlib target.
So it's intended for cases like using zlib : 1.2.7 : <source>C:/Devel/src/zlib-1.2.7 : <toolset>msvc ; using zlib : 1.2.7 : <source>/opt/src/zlib-1.2.7 : <toolset>gcc ; ? Either way, in general, when I see lib1 having a CMake dependency on foo.1 and lib2 having a dependency on foo.2, ignoring the suffix doesn't seem correct. I could add a specific check for `zlib.*` and `bzip2.*` but this will only work for Iostreams. What's the intended path forward (in general, not specifically for the CMake configurations) when a second Boost library wants to use zlib and bzip2?
AMDG On 3/10/19 11:33 AM, Peter Dimov via Boost wrote:
Steven Watanabe wrote:
The purpose of that incrementing library-id, as far as I can infer, is > to enable two libraries to have their own private zlib dependencies.
That's not really correct. The reason for the library-id is to make sure that target alternative selection only happens at the top level on the /zlib//zlib target.
So it's intended for cases like
using zlib : 1.2.7 : <source>C:/Devel/src/zlib-1.2.7 : <toolset>msvc ; using zlib : 1.2.7 : <source>/opt/src/zlib-1.2.7 : <toolset>gcc ;
?
Yes.
Either way, in general, when I see lib1 having a CMake dependency on foo.1 and lib2 having a dependency on foo.2, ignoring the suffix doesn't seem correct.
I could add a specific check for `zlib.*` and `bzip2.*` but this will only work for Iostreams.
a) The extension should be stripped unconditionally: lib-names = $(lib-names:S=) ; b) foo.1, foo.2 etc, should be sorted out by foo.cmake. The exact suffix used is highly unstable and should not be used in any way outside of a single run of b2. The choice will need to be made based on the original requirements, instead. (<toolset>gcc or <toolset>msvc in your example.)
What's the intended path forward (in general, not specifically for the CMake configurations) when a second Boost library wants to use zlib and bzip2?
I'm not sure. Before boost_install, I would have said that it will Just Work (TM). I still think that should be the goal: specify the dependency normally, and let boost_install and/or zlib sort out exactly what needs to be installed and how. In Christ, Steven Watanabe
Steven Watanabe wrote:
a) The extension should be stripped unconditionally: lib-names = $(lib-names:S=) ;
Doesn't seem so simple. I stripped the suffixes in boost-install, then tried to `boost_install boost_zlib` in the Iostreams Jamfile when ZLIB_SOURCE is set, but it doesn't work, because the target isn't called `boost_zlib`, it's `boost_zlib.1`.
What's the intended path forward (in general, not specifically for the CMake configurations) when a second Boost library wants to use zlib and bzip2?
I'm not sure. Before boost_install, I would have said that it will Just Work (TM).
Wouldn't it hit the `errror` at https://github.com/boostorg/build/blob/develop/src/tools/zlib.jam#L162 ?
AMDG On 3/11/19 4:25 PM, Peter Dimov via Boost wrote:
Steven Watanabe wrote:
a) The extension should be stripped unconditionally: lib-names = $(lib-names:S=) ;
Doesn't seem so simple. I stripped the suffixes in boost-install, then tried to `boost_install boost_zlib` in the Iostreams Jamfile when ZLIB_SOURCE is set, but it doesn't work, because the target isn't called `boost_zlib`, it's `boost_zlib.1`.
IOStreams shouldn't refer to boost_zlib. It should use /zlib//zlib conditioned only on NO_ZLIB/NO_COMPRESSION. I'm not certain that this will work in all cases, right now. It should, correctly, do nothing when there is no zlib at all, but I'm not sure what it will do for pre-built libraries Actually, I take that back. I never considered the possibility of users referring to targets other than /zlib//zlib. If I make /zlib//<whatever-was-given-as-build-name> a visible target, I'll be able to fix some long standing issues that I've been ignoring, i.e. what happens when multiple projects specify different build-names. For now, however, use /zlib//zlib.
What's the intended path forward (in general, not specifically for the > CMake configurations) when a second Boost library wants to use zlib and > bzip2?
I'm not sure. Before boost_install, I would have said that it will Just Work (TM).
Wouldn't it hit the `errror` at
https://github.com/boostorg/build/blob/develop/src/tools/zlib.jam#L162
?
No. is-default is true. It will arbitrarily select the first one to be called, which is fine since all the uses inside Boost should be identical. In Christ, Steven Watanabe
Steven Watanabe wrote:
IOStreams shouldn't refer to boost_zlib. It should use /zlib//zlib...
Yes, I belatedly figured that part out, too. This works: https://github.com/boostorg/iostreams/commit/703e9a077b899417ead9fb6c35db8f0...
conditioned only on NO_ZLIB/NO_COMPRESSION.
Well, no. If zlib is not built from source, we shouldn't be installing a CMake configuration file for boost_zlib. Although... maybe we should, as long as it somehow refers in its IMPORTED_LOCATION to the preinstalled library. Will this work?
AMDG On 3/11/19 5:22 PM, Peter Dimov via Boost wrote:
Steven Watanabe wrote:
IOStreams shouldn't refer to boost_zlib. It should use /zlib//zlib...
Yes, I belatedly figured that part out, too. This works:
https://github.com/boostorg/iostreams/commit/703e9a077b899417ead9fb6c35db8f0...
conditioned only on NO_ZLIB/NO_COMPRESSION.
Well, no. If zlib is not built from source, we shouldn't be installing a CMake configuration file for boost_zlib.
Ah. I forgot the details of boost-install. I was thinking that the cmake files were based on virtual-targets instead of main-targets. Also, checking ZLIB_SOURCE is wrong, because the path can also be specified in user-config.jam.
Although... maybe we should, as long as it somehow refers in its IMPORTED_LOCATION to the preinstalled library. Will this work?
We still need to indicate the dependency on zlib somehow, right. If we don't create a boost_zlib.cmake file, then we'll need find_dependency(ZLIB) or something similar. In Christ, Steven Watanabe
Steven Watanabe wrote:
Also, checking ZLIB_SOURCE is wrong, because the path can also be specified in user-config.jam.
Yes, in principle. It's still significantly less wrong than it was. I'll need to try and see what happens with <source> in user-config. Probably nothing good, because one would expect neither <build-name> nor <tag> to be specified in such a case.
We still need to indicate the dependency on zlib somehow, right. If we don't create a boost_zlib.cmake file, then we'll need find_dependency(ZLIB) or something similar.
Yes, I had to hack around this by doing https://github.com/boostorg/boost_install/commit/cf4b78006e8f22fb883ad56ce58...
On Sat, Mar 9, 2019 at 5:37 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Tom Kent wrote:
* Can't create libraries for bzip2 and zlib (showstopper? anyone else seeing this?)
I haven't seen your initial report of this issue (on the users list?) but it's probably caused by this change:
https://github.com/boostorg/build/commit/5ad92cd76ff393792f30aa50688c95eff24...
Before that, -sZLIB_SOURCE=... on the b2 command line would have worked; after it, only the environment variable ZLIB_SOURCE is consulted.
I am setting BZIP2_SOURCE and ZLIB_SOURCE environmental variables, I haven't used the -s method.
AMDG On 3/9/19 4:12 PM, Tom Kent via Boost wrote: > On Sat, Mar 9, 2019 at 10:15 AM Marshall Clow via Boost < > boost@lists.boost.org> wrote: > >> <snip> > Looks the same as RC1 for me on Visual Studio. > * b2 with a relative prefix (and relative libdir/includedir) doesn't work I just fixed this one in develop (after the RC). > * Can't create libraries for bzip2 and zlib (showstopper? anyone else > seeing this?) I can replicate this. It happens because of Peter's refactoring of the install rule. Each project is now expected to provide install and stage targets, but zlib and bzip2 do not have this. As a result, they get skipped by the overall install. This is a showstopper, but I won't be able to get to it before Monday. In Christ, Steven Watanabe
Steven Watanabe wrote:
* Can't create libraries for bzip2 and zlib (showstopper? anyone else seeing this?)
I can replicate this. It happens because of Peter's refactoring of the install rule. Each project is now expected to provide install and stage targets, but zlib and bzip2 do not have this. As a result, they get skipped by the overall install.
This doesn't sound good, if I understand correctly. zlib.jam is part of Boost.Build and it's not supposed to depend on tools/boost_install.
AMDG On 3/9/19 4:54 PM, Peter Dimov via Boost wrote:
Steven Watanabe wrote:
* Can't create libraries for bzip2 and zlib (showstopper? anyone else > seeing this?)
I can replicate this. It happens because of Peter's refactoring of the install rule. Each project is now expected to provide install and stage targets, but zlib and bzip2 do not have this. As a result, they get skipped by the overall install.
This doesn't sound good, if I understand correctly. zlib.jam is part of Boost.Build and it's not supposed to depend on tools/boost_install.
Yep. I think we can solve this be having the IOStreams Jamfile pass zlib to boost_install. I'll need to make sure that it safely turns into a no-op if zlib is not being built from source. In Christ, Steven Watanabe
Tom Kent wrote:
* b2 with a relative prefix (and relative libdir/includedir) doesn't work
This should be fixed in https://github.com/boostorg/build/commit/42aeed7ff1d8f2554b57371604c33ed6b27... https://github.com/boostorg/build/commit/f15a84a815bec7897d73fdace3bc4bcf219...
* Can't create libraries for bzip2 and zlib (showstopper? anyone else seeing this?)
And this should be fixed in https://github.com/boostorg/boost_install/commit/5bc0961483e5b95b72032e2c343... Marshall, please let us know if you want these fixes in master for an RC3.
participants (4)
-
Marshall Clow -
Peter Dimov -
Steven Watanabe -
Tom Kent