Re: [boost] Cmake

Subject: Re: [boost] Cmake
From: Gary Furnish (gfurnish_at_[hidden])
Date: 2017-06-24 17:03:36

As a boost user I need to know that some change someone put into
master on any given release to fix bug A did not introduce bug B.  In
practice this means my tests need to be well designed enough to test
if boost breaks.  As an example there was a heisenbug a few years ago
in UUID where compare randomly broke on SIMD machines.  To be able to
diagnose bugs like this you need the exact build of boost to be a
known quantity down to the compilation switches.  Plus sometimes you
run on new compilers that might have separate ABIs/features then the
packages you could download with a distro.

On Sat, Jun 24, 2017 at 10:22 AM, Stefan Seefeld via Boost
<boost_at_[hidden]> wrote:
> On 24.06.2017 12:08, Gary Furnish via Boost wrote:
>> On Sat, Jun 24, 2017 at 9:57 AM, Stefan Seefeld via Boost
>> <boost_at_[hidden]> wrote:
>>> On 24.06.2017 04:59, Peter Dimov via Boost wrote:
>>>> There is considerable interest in Boost supporting CMake, but it seems
>>>> that everyone has different ideas as to what this support will entail.
>>>> After deliberation and discussions, I have identified the following
>>>> (separate) scenarios:
>>> I'm a bit confused by the listing, as you use the term "user" in quite
>>> different ways.
>>>
>>>> 1. The user installs a Boost release as usual with `b2 install`, which
>>>> makes the installation visible to CMake and usable via
>>>> find_package(boost_libname).
>>>>
>>>> 2. The user brings several Boost libraries as git submodules into his
>>>> CMake-based project and uses add_subdirectory in his CMakeLists.txt to
>>>> link to them.
>>>>
>>>> 3. The user uses CMake to install an individual Boost library, which
>>>> is then available for find_package.
>>>>
>>>> 4. The user uses CTest to run the tests of an individual Boost library.
>>>>
>>>> 5. CMake is supported as a way to build and install the entire Boost,
>>>> in place of b2.
>>>>
>>>> 6. CTest is supported as a way to run the tests for the entire Boost,
>>>> in place of b2.
>>> All but 1) are addressed at boost developers, i.e. people who want to
>>> build (, test, etc.) boost itself. Only 1) is concerned about users who
>>> want to use boost as external dependency to their own project.
>>>
>>>> At the moment, I think that we should concentrate on (1) and (2) as
>>>> providing most bang for the buck.
>>> To be honest, I don't quite understand 2). Why do you want to support
>>> building boost (or parts of it) as an integral part of something else ?
>>> Modularity and encapsulation doesn't seem to have any value to you, or
>>> does it ?
>>>
>> As good as modularity and encapsulation sound they make it very hard
>> to test code.
> Huh ? Test what code ? As a boost user I want to test *my* code, not
> boost. (Of course, that doesn't prevent me from also playing the role of
> a boost developer / tester, but that are two very different things.
>
>>   Even different distributions sometimes patch packages
>> of the same version the same without anyway to detect this.  If you
>> don't build boost as part of your program you can't certify its bug
>> free with tests.  And forget certification of bug free between
>> different versions of boost!
> Yeah, now we are plainly in the discussion of Boost's lack of API and
> ABI stability.
>
>>   It is simply not an option to rely on
>> external libraries when stuff must test clean.
> I strongly disagree. Rigorous testing (which includes the clear
> distinction between unit testing and integrated testing) doesn't
> invalidate encapsulation. Quite the opposite !
>
>>   What mechanism you use
>> to do this various but modularity and encapsulation are a dream.
>
> Very sad, but luckily doesn't reflect my experience.
>
>         Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost