I've merged my develop branch into the the master, waited some time, and reviewed the test results here: https://www.boost.org/development/tests/develop/developer/serialization.html . Given that we intend to release soon, I have a few questions: a) I don't see any windows compilers here. WTF? b) If I switch to "Release View" (upper left hand corner) I expect to see test runs for the master branch. I just get an error message. I can't see how we can think of doing a release with having these issues resolved. Robert Ramey
On Thu, Nov 2, 2023 at 4:31 PM Robert Ramey via Boost
I've merged my develop branch into the the master, waited some time, and reviewed the test results here:
https://www.boost.org/development/tests/develop/developer/serialization.html . Given that we intend to release soon, I have a few questions:
a) I don't see any windows compilers here. WTF? b) If I switch to "Release View" (upper left hand corner) I expect to see test runs for the master branch. I just get an error message.
I can't see how we can think of doing a release with having these issues resolved.
Robert Ramey
Agree that we can't move into release without this. I raised this last week here; https://lists.boost.org/Archives/boost/2023/10/255210.php There is an older thread without resolution here: https://lists.boost.org/Archives/boost/2023/09/255010.php It sounds like something broke in the code that automatically copies (symlinks where available) the headers in as needed. Tom
On 11/3/23 16:02, Tom Kent via Boost wrote:
On Thu, Nov 2, 2023 at 4:31 PM Robert Ramey via Boost
wrote: I've merged my develop branch into the the master, waited some time, and reviewed the test results here:
https://www.boost.org/development/tests/develop/developer/serialization.html . Given that we intend to release soon, I have a few questions:
a) I don't see any windows compilers here. WTF? b) If I switch to "Release View" (upper left hand corner) I expect to see test runs for the master branch. I just get an error message.
I can't see how we can think of doing a release with having these issues resolved.
Robert Ramey
Agree that we can't move into release without this.
I raised this last week here; https://lists.boost.org/Archives/boost/2023/10/255210.php
There is an older thread without resolution here: https://lists.boost.org/Archives/boost/2023/09/255010.php
It sounds like something broke in the code that automatically copies (symlinks where available) the headers in as needed.
My recollection is that there were two problems: 1. process_jam_log is not building because by default it is being compiled with MSVC-10, which doesn't support C++11, which is now required by process_jam_log dependencies. Resolution: make sure process_jam_log is compiled with the latest MSVC (i.e. 14.x), e.g. by passing it in the command line as `toolset=msvc-14.3`. Alternatively, update user-config.jam to default to the latest MSVC version and explicitly pass `toolset` when running the tests. 2. Some headers are not automatically installed for configure-time checks. Resolution: always invoke `b2 headers` prior to running the build. Automatic generation of unified include tree has never worked reliably, and likely never will. Both resolutions require modification of the testing scripts and/or infrastructure, I'm not sure who maintains those now. You could argue that Boost.Build could be modified to fix those issues, and that's probably true. However, even if it was fixed, I would argue that the testing scripts should be fixed anyway to be more reliable and predictable.
On Fri, Nov 3, 2023 at 9:51 AM Andrey Semashev via Boost
On 11/3/23 16:02, Tom Kent via Boost wrote:
On Thu, Nov 2, 2023 at 4:31 PM Robert Ramey via Boost
wrote: I've merged my develop branch into the the master, waited some time, and reviewed the test results here:
https://www.boost.org/development/tests/develop/developer/serialization.html . Given that we intend to release soon, I have a few questions:
a) I don't see any windows compilers here. WTF? b) If I switch to "Release View" (upper left hand corner) I expect to see test runs for the master branch. I just get an error message.
I can't see how we can think of doing a release with having these issues resolved.
Robert Ramey
Agree that we can't move into release without this.
I raised this last week here; https://lists.boost.org/Archives/boost/2023/10/255210.php
There is an older thread without resolution here: https://lists.boost.org/Archives/boost/2023/09/255010.php
It sounds like something broke in the code that automatically copies (symlinks where available) the headers in as needed.
My recollection is that there were two problems:
1. process_jam_log is not building because by default it is being compiled with MSVC-10, which doesn't support C++11, which is now required by process_jam_log dependencies. Resolution: make sure process_jam_log is compiled with the latest MSVC (i.e. 14.x), e.g. by passing it in the command line as `toolset=msvc-14.3`. Alternatively, update user-config.jam to default to the latest MSVC version and explicitly pass `toolset` when running the tests.
2. Some headers are not automatically installed for configure-time checks. Resolution: always invoke `b2 headers` prior to running the build. Automatic generation of unified include tree has never worked reliably, and likely never will.
Both resolutions require modification of the testing scripts and/or infrastructure, I'm not sure who maintains those now.
You could argue that Boost.Build could be modified to fix those issues, and that's probably true. However, even if it was fixed, I would argue that the testing scripts should be fixed anyway to be more reliable and predictable.
Yes, the testing scripts should be more reliably resilient. As for b2.. (1) It can't be fixed in b2. As it's not possible for b2 to read user's minds. Hence the existence of the multiple ways to tell b2 what toolset to build with. (2) When we have the Boost modular arrangement it will be possible to not use "b2 headers" at all. And hence that problem will be "fixed". -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
René Ferdinand Rivera Morell wrote:
Yes, the testing scripts should be more reliably resilient. As for b2..
(1) It can't be fixed in b2. As it's not possible for b2 to read user's minds. Hence the existence of the multiple ways to tell b2 what toolset to build with.
(2) When we have the Boost modular arrangement it will be possible to not use "b2 headers" at all. And hence that problem will be "fixed".
The fact that the automatic header symlink generation works for normal targets and fails for targets passed to configure.builds leads me to think that there is a problem in b2 somewhere, but I have no idea what or where.
On Fri, Nov 3, 2023 at 10:57 AM Peter Dimov via Boost
René Ferdinand Rivera Morell wrote:
Yes, the testing scripts should be more reliably resilient. As for b2..
(1) It can't be fixed in b2. As it's not possible for b2 to read user's minds. Hence the existence of the multiple ways to tell b2 what toolset to build with.
(2) When we have the Boost modular arrangement it will be possible to not use "b2 headers" at all. And hence that problem will be "fixed".
The fact that the automatic header symlink generation works for normal targets and fails for targets passed to configure.builds leads me to think that there is a problem in b2 somewhere, but I have no idea what or where.
Unfortunately I have no idea either. As I did not write any of the automatic header symlink generation. And, yes, there are almost certainly one or more bugs in that. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net
Tom Kent wrote:
Agree that we can't move into release without this.
I raised this last week here; https://lists.boost.org/Archives/boost/2023/10/255210.php
There is an older thread without resolution here: https://lists.boost.org/Archives/boost/2023/09/255010.php
It sounds like something broke in the code that automatically copies (symlinks where available) the headers in as needed.
This https://github.com/boostorg/regression/commit/80d44c58655779fbfa0dee9b473ed2... should fix it.
On Fri, Nov 3, 2023 at 12:28 PM Peter Dimov via Boost
Tom Kent wrote:
Agree that we can't move into release without this.
I raised this last week here; https://lists.boost.org/Archives/boost/2023/10/255210.php
There is an older thread without resolution here: https://lists.boost.org/Archives/boost/2023/09/255010.php
It sounds like something broke in the code that automatically copies (symlinks where available) the headers in as needed.
This
https://github.com/boostorg/regression/commit/80d44c58655779fbfa0dee9b473ed2...
should fix it.
That does appear to have fixed it. Regression matrix is starting to populate for windows. I'll try to bring up another runner in a bit to attack it a bit faster. Tom
On Nov 4, 2023, at 8:15 AM, Tom Kent via Boost
On Fri, Nov 3, 2023 at 12:28 PM Peter Dimov via Boost
wrote: Tom Kent wrote:
Agree that we can't move into release without this.
I raised this last week here; https://lists.boost.org/Archives/boost/2023/10/255210.php
There is an older thread without resolution here: https://lists.boost.org/Archives/boost/2023/09/255010.php
It sounds like something broke in the code that automatically copies (symlinks where available) the headers in as needed.
This
https://github.com/boostorg/regression/commit/80d44c58655779fbfa0dee9b473ed2...
should fix it.
That does appear to have fixed it.
Regression matrix is starting to populate for windows. I'll try to bring up another runner in a bit to attack it a bit faster.
Thanks, Peter and Tom! — Marshall
participants (6)
-
Andrey Semashev
-
Marshall Clow
-
Peter Dimov
-
René Ferdinand Rivera Morell
-
Robert Ramey
-
Tom Kent