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