On 14.09.18 13:44, Mike Dev via Boost wrote:
Dear all,
unless I'm encountering an overwhelming resistance to this idea here on the ml, I intend to create a batch of PRs that introduce minimal cmake support to a large subset of boost libraries (maybe even all).
[snip]
Finally, please don't nick-pick this to death. I'd like to have a more complete solution too, but it isn't coming, so let's do the minimum we can and go on from there. Note that the advantage of such a minimal solution is also that there are very few design decisions to make that may later turn out to be wrong and then create a maintenance burden.
The only things that are visible on an interface level (and thus should remain reasonable stable) are:
[snip]
I have a working prototype: https://github.com/raffienficiaud/boost-cmake Please give a try, it is very easy to use and it is still working. It is honoring the inter-libraries dependencies. It has a nice design IMO, and is handling project dependencies in an ok fashion, with very little overhead. An additional plan was to integrate the automatic dependency tool discovery in it (made by Peter Dimov). Quickbook is here (compilation), and I am almost done with exposing functions to compile the doc of each project. There is something I was not able to achieve though: detecting the version of the CRT for Visual. This affects apparently some project dependencies (regex + libICU). I would be happy to discuss about this offline, with a set of interested people. In particular, the design is not intrusive and it lets library expose their cmake inside boost or independently. I stopped working on this some time ago because I was lacking time, but I am interested in resurrecting it, and it is on my todo list. Best, Raffi