From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2021-01-27 08:48:33
>> Meanwhile other libraries like Boost.Serialization (and consumers of
>> same) also make their own assumptions about things like endianness
>> and type structure, which may not matter too much in isolation but
>> becomes very important if you're intending to use it as a portable
>> network or disk format.
>
> I think then it is important for the libraries in which some of the
> code is tailored to a platform/architecture to test on other
> platform/architectures than Intel, but for the large number of Boost
> libraries which have no direct dependencies on a platform/architecture
> I do not see that it is of much importance. Simply because library XXX
> uses Boost.SmartPtr does not mean that testing on ARM is going to show
> anything of use for library XXX, which testing Boost.SmartPtr on ARM
> would not itself show.
Fully agree with the first point, as usual: Every branch needs to/should
be tested.
However usually bugs show up in complex scenarios, so testing the
downstream lib might show up bugs which the author/maintainer of the
lower-level lib didn't think about. So there is still worth in testing
that. Weekly is likely enough to not burn to many resources.
However the question still is: How/where can those (low level) libs be
tested on other hardware? Travis is basically dead for us and setting up
CI is hard (see prior discussion), so testing Boost as a whole on many
archs, OSes, ... might still be the easiest solution as it means a
single setup to be maintained (see the integration tester approach,
which I'd say needs some love)
Alex