Re: [boost] Boost.test failures in develop

Subject: Re: [boost] Boost.test failures in develop
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-10-04 13:37:38

On 10/4/15 1:10 AM, Gennadiy Rozental wrote:
> Tom Kent <lists <at> teeks99.com> writes:
>
>> Unfortunately I know lots of places that are still using msvc-8.0, so I
>> don't see that full move happening any time soon
>
> Why would we want to wait for some places using 12 year old compiler? More
> importantly who is going to maintain the code for it? If they want to stick
> with older compiler, they can stick with older boost release.

I think this betrays a difference in what Boost or what Boost should be.

To some, it seems that "The Boost Libraries" is sort of like a product 
like windows, or Clang or whatever - a large piece of code with lots of 
facets which is accepted/rejected as a whole.  This is what most of us 
deal with in our day jobs so it seems natural to look at Boost this way.
This view leads to coupling among libraries, requirements for 
coordination on testing policies, and things like that.

I don't think this is a good think

I think a better way to look at Boost is a collection of more loosely 
coupled software components.  The only coupling is to a minimal set of 
of practices and requirements: Compatiblity with C++, Formal Review, 
directory structure, and documentation requirements.  In this view, 
there is no place for requiring a specific library for testing, 
requiring that some particular version of C++ not be supported.

I have no problems with the current setup as regards the serialization 
library - a library which has more stringent requirements than most in 
the support of older code, platforms and data sets.

I use

a) Xcode/CLang with C++11 enabled for development as it's very 
convenient for this.

b) I use my own version lightweight test as it's enough for my needs and 
I've found it simpler and more stable than other systems.  I haven't 
changed any code in it for ten years!.  A big problem in using boost 
test on the test matrix is that one is testing my development code with 
boost test development code so when the later has some issue, it spills 
over into my domain - and I already have my hands full.

c) I have my whole boost development tree to set to master branch so I'm 
testing against the next release. Only the serialization submodule is 
set to develop (or a feature branch).

d) Almost most all code is C++11/C++03 agnostic.

e) Some code is C++11+ specific.  This is conditioned with BOOST_NO... 
macros.  Some tests are conditioned on these macros as well.

f) After I get clean results with Xcode/CLang C++11 I test with GCC with 
C++03 selected.  Tweak the library to address any test failures
then upload to development branch of the repository.

This is a simple effective system which has worked well for me and I 
believe for the wide variety of users of the serialization libraries. It 
is not particularly difficult or time consuming to maintain - given the 
size and complexity of the library itself.

Notice that it does NOT result in maintaining two versions of the 
library.  A very small portion of the code is conditional.

I don't think can or should try to impose requirements/prohibitions on 
supporting old libraries from the top down.  It isn't a requirement, but 
it it can't be prohibited either.

If the author of Boost.Test feels he can't support older compilers, 
that's his decision of course.  But he should be aware it's going to cut 
his "market share" and encourage the usage of alternatives.

Robert Ramey