On 9/14/2018 10:05 AM, Alexander Grund via Boost wrote:
The major problem I see are the variants.
- b2 can build multiple variants in one go (static, dynamic, runtimes...) - Encoding these variants has to be reflected in the target names/aliases
CMake FindBoost solves this by requiring to set some variables to select a set of variants and set the appropriate aliases to this set.
Think about how you reflect this in the CMake buildsystem. E.g. some libraries may depend explicitly on a static or dynamic version of another library (which can be expressed in bjam)
The practical problem for most libraries, which are largely header-only, is converting the library jamfile for tests and building docs into CMake terms. Building non-header only libraries is actually much less of a problem for converting from Boost Build to CMake, even if it will get the vast majority of the comments This won't be to bad either once the variants problem above is solved. CTest is quite powerful so except for a few corner cases I expect it to be straight forward.
CTest has absolutely no notion of compile-time testing. This was mentioned to CMake on their mailing list a long time ago and got the usual yawns from the CMake people.