On 11/17/15 12:47 AM, Domagoj Saric wrote:
On 17.11.2015. 6:01, Robert Ramey wrote:
There's no reason you can't do it for your own library. <...>
On the other hand, boost build does somethings that CMake can't do.
Such as (an honest question)?
A fair question. I spent a fair amount of time figuring out CMake in the course of working on a non-boost project. I decided to capture my thoughts and experience on a page in the Boost Library Incubator which summarized my experiments with alternative build systems. I found all the build systems lacking in some way. I don't think I'm alone as this page is the single most popular page in the whole incubator. So I would suggest that people can look at that for a complete view. But here are some things that immediatlly come to mind. a) Bjam has a steep learning curve. CMake seems easier and it is - but it's still too complicated. 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. 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. 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. 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. 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'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. Robert Ramey