From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-11-03 14:50:03
On 11/3/23 16:02, Tom Kent via Boost wrote:
> On Thu, Nov 2, 2023 at 4:31 PM Robert Ramey via Boost <boost_at_[hidden]>
> 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://listarchives.boost.org/Archives/boost/2023/10/255210.php
>
> There is an older thread without resolution here:
> https://listarchives.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.