Re: [boost] Boost.test failures in develop

Subject: Re: [boost] Boost.test failures in develop
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-10-05 16:43:05

On 10/5/15 1:20 PM, Gennadiy Rozental wrote:
> Robert Ramey <ramey <at> rrsd.com> writes:
>
>> 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.
>
> For this we need a process of independent boost.XXX library version-ing and
> release procedures/schedule.

It's a question of degree.  Libraries can be more or less tightly 
coupled.  I one's library development depends heavily on Boost.Test it's 
coupled to Boost.Test.  Otherwise it's not. I would argue that less 
coupling is better than more coupling and I think the structure
of Boost encourages that.

>> 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).
>
> Unfortunately this is not the way test runners operate

LOL - That's my point exactly.  And it is one of the sources of these 
problems.  If things were run the way I suggest, you could make a 
temporary mistake in development of Boost.Test which wouldn't ripple 
though to all the libraries which use it for development testing.  It 
would make your life a lot easier.

>> 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.
>
> In few cases this can work out like this. In many other cases maintaining
> c++03 compatibility can make library obsolete(I am not talking about my
> library). C++11/C+14 modern C++ code can and *should* look significantly
> different, with different API and implementation

It makes no economic sense to go back and re-write working code to just 
because there is a new standard.  There is no benefit unless one want's 
to add features. Some might say that it makes maintenance easier - but 
this is a decision that only a the library maintainer is qualified to make.
>
>
> This statement is conditioned on several big IFs IMO, but I am not going to
> argue.

Hmmm - there aren't any IFS here:

 >> If the author of Boost.Test feels he can't support older compilers,
 >> that's his decision of course.

Hmmm - I presume agree with this.

 >> But he should be aware it's going to cut
 >> his "market share" and encourage the usage of alternatives.

I doubt anyone would dispute this.

Robert Ramey