Re: Boost test matrix

From: René Ferdinand Rivera Morell (grafikrobot_at_[hidden])
Date: 2023-11-03 14:58:55

On Fri, Nov 3, 2023 at 9:51 AM Andrey Semashev via Boost
<boost_at_[hidden]> wrote:
>
> 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://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