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