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

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

Hi Raffi, Am Wednesday 18 November 2015, 10:20:30 schrieb Raffi Enficiaud:

Le 17/11/15 17:06, Robert Ramey a écrit :

...

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

Those commands are meant for feature detection. Robert meant "compile- fail"/"compile" and "link-fail"/"link" unit test rules, analogues to the "add- test" function for executables. With all bells and whistles, of course. That means they should show up in the statistics, show in the CDash dasbboard etc. pp. Setting up even normal tests usually means writing some boilerplate cmake code. Compare [ run-test foo.cpp ] with add_executable( foo foo.cpp ) add_test(foo foo) not mentioning setting up dll paths on windows and whatnot. I think that cmake 3(.4) has at least solved some of the dependency issues by borrowing the "usage-requirements" from Boost.Build. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

Vladimir Prus wrote:

On 17-Nov-15 11:37 AM, Stephen Kelly wrote:

...

Note that for users of boost, there would be a great benefit if boost.build would generate cmake packages with imported targets.

I can help if someone who maintains boost.build wants to pursue that.

FWIW, this proposal is something that can be actually implemented, and probably will help users.

Great, I have started a thread on the boost build list about this. Thanks, Steve.

Hi Robert, Am Tuesday 17 November 2015, 14:41:07 schrieb Robert Ramey:

On 11/17/15 1:52 PM, Stephen Kelly wrote:

...

Vladimir Prus wrote:

...

On 17-Nov-15 11:37 AM, Stephen Kelly wrote:

...

Note that for users of boost, there would be a great benefit if boost.build would generate cmake packages with imported targets.

I can help if someone who maintains boost.build wants to pursue that.

FWIW, this proposal is something that can be actually implemented, and probably will help users.

I appreciate your efforts to improve boost, but I would like to discourage you from pursuing this. Boost Build is already too complex for most of us to understand.

Using Boost.Build is usually simple. And I don't think that a CMake solution for all of Boost would be simple. I've closely followed the first CMake attempt. I've been really impressed by lots of boilerplate macros needed back then. I guess CMake 3.x has lots of improvements, but it will still need some tweaking. At least the modularisation code can be omitted now.

This idea follows the strategy - build it all in so that it works automagically. But the problem is that the job is too varied and to complex for this to work. We then end up with something that usually works - until it doesn't.

Well, in the end we need an "automagic" solution for all of Boost. Although I agree that small steps are better.

Please consider a different approach.

Make a Boost/CMake cheat sheet which would serve as a "template" for library authors to use to make their own CMakeList.text files. Then be available to help out anyone who asks for it.

That would be a nice addition. But I'd prefer some immediate improvements for Boost users working with CMake now.

I believe it would be more effective in getting Boost to work better with CMake. I already spent some time on this for the inclubator. But my effort isn't complete - it addresses only the running of test on header only libraries. So there is lots of opportunity to make an impact here.

As always. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany

On 11/18/15 11:39 AM, Jürgen Hunold wrote:

...

Make a Boost/CMake cheat sheet which would serve as a "template" for library authors to use to make their own CMakeList.text files. Then be available to help out anyone who asks for it.

That would be a nice addition. But I'd prefer some immediate improvements for Boost users working with CMake now.

Hmmmm - that's exactly what I was I thought I was proposing. Someone could make a "cheatsheet" which would be applicable to header only libraries in about a day. In fact, my attempt at such a "cheatsheet" might already be good enough - thought it might benefit from refinement by some CMake expert. Note also that the serialization library contains a CMakeList.txt file which I use for working on the serialization library which might be worthy of examination.

So there is lots of opportunity to make an impact here.

Why not address this right now? What's stopping any author of a header only library from doing this right now? Why not check over my cheatsheet, make any enhancements/corrections necessary and announce on the list that authors of header only libraries are encouraged to incorporate CMake into their testing options and that help is available? Why not start this right now? It would only take a day or two. And if that effort is successful, on could expand/enhance it to cover the compiled libraries. If the effort is not successful, then we'll have learned something at very little investment of effort. Robert Ramey

On 11/17/15 12:37 AM, Stephen Kelly wrote:

Louis Dionne wrote:

...

Dear Boost,

I'd like to inquire about the status of the CMake-ification of Boost that had been started a while ago. AFAICT, the effort is completely stopped now; is this correct?

Yes. It can never reach a completeness because the Boost community doesn't want it, so the effort stopped.

Note that for users of boost, there would be a great benefit if boost.build would generate cmake packages with imported targets. Keeping boost.build and generating such files (as Qt does with qmake) could be an alternative area to make effort in and would provide more benefit in the shorter term for all external users of boost+cmake.

I can help if someone who maintains boost.build wants to pursue that.

...

Also, I'd like to poll the community to gauge interest in the rebirth of such an effort. __I'm not proposing myself to work on such a rebirth__, but I'm just curious to know what the community thinks about it. I, for one, would love to see it happen.

It can be revived at any time if there's a decision and a plan to complete it.

I was present at the creation and demise of the CMake effort. It has a lot of resources behind it. It's my belief that it was unsuccessful because it failed to appreciate the way boost works. (Ironic I know). I believe that if you want to make a change in Boost, the most effective way is to work from the bottom up. In this case this means encouraging individual authors to include CMake files for their projects. These can easily coexist with the bjam projects. And boost doesn't have means to prohibit authors from doing this. If you convince enough authors to do this - perhaps providing help for them - or documents or whatever, someone will then raise the question - why doesn't everyone do this? Of course then the usual brohaha will ensue - that's what we do. But the upshot will be someone will come up with a script which will walk through all the boost libraries and invoke just the CMake build - or maybe CMake if there is one and Bjam if there isn't or .... - I don't know. Eventually we could get to the place where the documentation is now. There is wide variety that has come about as fashions change but it seems to work OK. Personally, I don't see any reason why each library can't select it's own build system as it currently selects it's own documentation system. Basically, these ideas are demonstrated and promoted with the Boost Library Incubator. To summarize, individual authors are free to support CMake if they want and you're free to encourage and help them to do so. Even if you don't get every library on board - you'll still be making progress toward you desired goal - so have at it! BTW I'm willing to accept contributions to the boost library incubator which expand upon the topics there. Robert Ramey

On 11/17/15 9:24 AM, Alex wrote:

I was doing a bunch of work composing existing (non-Boost) CMake projects to be used as "submodules" in multi-module projects. I found that most CMake projects in the wild are almost impossible to compose if they weren't written with the composeability in mind from the start. Stuff like silently rewriting flags, changing output dirs, rewriting files in source dir (zlib is doing so) etc prevents the reuse. I ended up using new custom CMake scripts (based on existing CMake scripts, with the obvious burden to maintain them) for most of the projects.

Just my 2 cents.

Well, that's a lot more than 2 cents worth. It's very typical that projects seem to be a lot easier to do until you actually try to do them. Personally, I don't think we need to go "the full monty" in order for such an effort to be useful. If I could easily just one build one project at a time for cmake (as I can for the serialization library) I would be happy with that. I would be quite satisfied even if I had to manage the dependencies in my own brain. For example, I'd like to library X in my code for a medical device. So I'd like to run the tests on X and all the libraries that that X depends upon. I would be perfectly happy to just figure them out "by hand" and run them each by hand. This would be pretty simple. Others - making a website for example - wouldn't need this level of testing so they could might just test the library X or just skip the whole build/test step entirely. Of course each library would be different - as the documentation is now. That's not ideal. But I still think there's a good case to be made that library authors who want to can add CMake files to their libraries. Eventually, someone might come up with the magic to make them composible. This would be great but it's not necessary to make the effort worthwhile. Robert Ramey

Louis Dionne wrote:

Thanks to everybody for the comments. I, for one, think that a first step can be achieved by providing a CMake build system for new libraries, and slowly porting old libraries to CMake (without removing the old Boost.Build, of course). One thing that I also find useful is to provide a FindXXX.cmake module for my library, so it can be used as an external dependency to any CMake-based project quite easily.

That's the wrong thing to do. Provide XXXConfig.cmake instead. See my other mail in this thread for more. https://cmake.org/cmake/help/git-next/manual/cmake-packages.7.html Thanks, Steve.