On Fri, Jul 21, 2017 at 9:36 PM, Chris Glover via Boost
On Fri, 21 Jul 2017 at 13:25 Andrey Semashev via Boost < boost@lists.boost.org> wrote:
You'll also need whatever version of the *actual* build system CMake is generating for. So, we go from having 0 dependencies to at least 2: CMake itself, and the target build system.
-- chris
I think this exactly summarizes both advantage and Achilles heel of Boost.Build and the entire vision of Boost Community. ------------------------------------------------------------------------ Boost.Build is ok for 100% self contained library that needs nothing but itself and boost. This why declarative approach of BB actually works not bad and you can run from single line build of multiple variants. However the REAL WORLD isn't that "perfect". In real world scenarios boost libraries require complex configuration and depend on 3rd part libraries. This requires complex configuration - search for libraries, headers running some checks. This makes BB declarative/tags approach programming nightmare. As the author of Boost.Locale library that has complex dependencies and build options I can say it is impossible to maintain complex projects with BB. Why: 1. Support of basic features given by any normal REAL WORLD build system barely exists (library search configuration options etc) 2. Documentation isn't good and it was this for years. 3. Knowledge exits only for few people. Do you want a proof? Please find me a tutorial how to search a 3rd part library or complete reference documentation for that. I mean: (a) find if library exists (with optional search path) (b) find if headers exists (with optional search path) (c) given this turn on and off some feature of fail library build (d) propagate results to tests. And this is one of the most basic and trivial feature that exists in every real world build system. And now take a look on this code: https://github.com/artyom-beilis/cppcms/blob/master/booster/CMakeLists.txt#L... Lines 124-145 this is how I search ICU for Boost.Locale And this is how it is done in BB: https://github.com/boostorg/locale/blob/develop/build/Jamfile.v2#L63 Lines 63-190 I look at the code and I can barely understand what is written. Options that are in use aren't documented. And only very few people on this list can describe me what is going on. So please all of you complaining how Boost.Build is great in comparisons to cmake and what cmake can't do. I want you to tell what BB can't do? It can't support complex projects that aren't self contained properly. I want also relate to another issue that was pointed there? That CMake can't run ./b2 toolset=msvc-12,msvc-14,mingw Boost.Build can't either once a 3rd part library required as search paths for each need to be different. What about running? ./b2 -sICU_PATH=/opt/icu56 .. ./b2 -sICU_PATH=/opt/icu59 .. And this is one of the principle issues of BB - its declarative way of providing configuration. --------- So I'm really thrilled by moving to CMake, not because it is perfect build system - it isn't. But at least it (a) feature rich (b) well documented (c) it works for many cases BB would required custom build macros So instead of trying to live in pure world without dependencies please consider thous who can't afford it. Artyom Beilis