Re: [boost] Cmake

24 Jun 2017


      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
 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
 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