Le 17/11/15 17:06, Robert Ramey a écrit :
[snip]
a) Bjam has a steep learning curve. CMake seems easier and it is - but it's still too complicated.
Also the community support in cmake is much stronger.
b) Bjam permits one to have one build file refer to another. CMake might permit this, but it's sufficiently unobvious that I couldn't figure it out. This is useful for us. For example if I want to build (and run) tests for the serialization library, it will automatically build the libraries it requires and nothing more - just by invoking the build script from within the test directory. CMake might be able to do this - but it's very non-obvious how one would do this.
CMake works with targets. In bjam we can create a target (conjunction of source files and compilation options) on the dependent side (eg "/boost/thread//boost_thread/<link>static"), in cmake all targets should be declared prior to any reference (so "target_link_libraries(boost_test boost_thread_static)" will not work if boost_thread_static has not been declared).
c) CMake couples all your directories together by sprinkling CMakeList.txt files throughout one's directory structure. This is very intrusive and inconvenient as far as I'm concerned. Bjam is better in this regard.
I do not see any difference between bjam and cmake in that regard. We have a Jamfile, we should have a corresponding CMakeList.txt.
d) CMake "language" is simpler than BJam "language". There both very inconvenient to use and understand. But the "language"s, clunky though they are are good enough for the task. The real problem is that building applications these days is very, very, very complicated. It's evolved over many years as applications have gotten more and more elaborate. Basically, it's a hard problem and the difficulty of making tools to help reflect that.
I agree that both are rather difficult (and have rather "nice" gotchas as). It however appeared to me that cmake is simpler to debug (better error messages).
e) CMake builds the "build script" which Bjam builds the app. This means that CMake can build my IDE for the project and BJam can't. I use Apple XCode for an IDE. Previously I used MSVC IDE to maintain the serialization library. In both cases, maintaining these IDE by hand was difficult and time consuming (MSVC) and pretty much impossible (XCode). This one feature has made CMake indispensible to me.
I think this is a killer feature, and this is the reason why some ppl (including me) are maintaining a separate CMakeLists.txt today. I also did it in such a way that I can compile the documentation, run the tests, etc. directly from my IDE,
f) CMake can't run a compile only test - or even more difficult - a compile test which has to fail - without some CMake gymnastics. At 67 I don't go in for gymnastics so much any more. Bjam handles this easily.
I can also say the same (although I am not yet 67). I do not want to learn a new language, especially when the languages I know are expressive enough for the tasks I am doing. BTW, what you mention should be easily achieved with try_compile/try_run - https://cmake.org/cmake/help/v3.0/command/try_compile.html - https://cmake.org/cmake/help/v3.0/command/try_run.html
I'm sure I could mention other stuff if I thought about it more. But my conclusion is - if you're doing a project which is not boost - use CMake. If you're doing a boost project - do both.
I should add the following: First, despite its age, cmake is "still" very active in its development, and very well maintained. Its community is reactive, it has great support on the development and user site through its mailing lists. It also supports a very large number of architectures and modules. Cmake can do things bjam can't, from the top of my head: - can be used together with cdash for the regression tests/dashboard. We will then not need to maintain the regression test suite within boost anymore. CDash is far from perfect, but it is effective. - can graph the dependencies without any additional tools. This kind of introspection is to me very important for scaling up. - it is meant to be modular: if someone needs to link with opencl, this capability is confined in a specific module of cmake, with specific maintainers. The burden of having a cross platform support for opencl is not carried by boost. Same goes for libtiff, doxygen, python, etc. BJam just assumes that the toolset is available from the command line. - it has installation and packaging semantics. I can for instance envision having boost binaries in their own PPA on Launchpad and distributing those quickly. I can also think about having a simple "make install" target. What cmake cannot do right now: - easily specify a dependent build variant. With bjam, I can write /boost/thread//boost_thread/<link>static , with cmake, we need to define a specific naming convention for that, and this will not achieve the flexibility of bjam anyway. - easily specify new requirements. While those options are appearing in cmake >= 3 and support main stream compilers, they do not have the same power/flexibility as for bjam. It is also not clear to me how to extend the already supported compiler features. - cmake does not produce symbolic or hard links (on the fly) as b2 header does. But honestly, "b2 header" is an installation step prior to the build: it can be done in cmake as well, and I believe it would be better to remove that step anyway. To be honest, I do think that there are ways in cmake to address its current limitations. The super project may provide functions to eg. generate documentation from quickbook/doxygen as it does now, and the libraries will just consume those functions. The superproject might just expect build+test+doc as umbrella targets (or naming them in a special manner such as "<library>_<target>": "atomic_build", "test_doc"...), and the libraries should implement those targets in such a way that it builds everything needed ("test_doc" should call doxygen and quickbook, "test_test" should build and run all tests in boost.test, etc). On the boost.test side, I am all for it for supporting this and for providing any template that might help and serve as starting point. Raffi