Re: [boost] CMake - one more time

Subject: Re: [boost] CMake - one more time
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2016-04-22 17:56:54

Le 22/04/16 à 19:42, Paul Fultz II a écrit :
>
>> On Apr 20, 2016, at 4:39 PM, Raffi Enficiaud <raffi.enficiaud_at_[hidden]> wrote:
>> <snip>
>> I do not like the current state of b2 for many reasons (even though I think it could be really a good build system), but CMake is not covering many features that are currently required by the boost superproject. Until the point where we can consistently build the lib (including the possibly many flavor of the same library - STATIC/SHARED at the same time, etc), run the tests, and generate the documentation (including the possibility to have the boostdoc/quickbook/doxygen toolchain), I do not see any *good* reason to move to cmake.
>
> Cmake can do all that you listed there. In addition, I found its easy to generate targets at configure time. So the Fit library actually adds additional tests to test examples and header files. Plus, I can create configuration headers based on whether a something compiles or runs. I believe BB can do the same using virtual targets or something, but I haven’t clearly figured it out.
>
Certainly, CMake can do everything with the appropriate effort. But so 
far, although I am a CMake user, I do not know how to do this:

- having the same target name with different target properties: like
   set(PROJECT_SRC ....)
   add_library(myproject SHARED ${PROJECT_SRC})
   add_library(myproject STATIC ${PROJECT_SRC})

   how do you do that? how do you refer to the appropriate variant?

- having a set of dependencies that is not driven by a high level 
CMakeLists.txt. You advocate the solution of packaging, but this does 
not target all platforms, and just translates the same problem to 
another layer to my opinion. As a developer, in order to work on a 
library X that depends on Y, you should install Y, and this information 
should appear in X (so this is an implicit knowledge). What this process 
does is that it put X and Y in some same level of knowledge: a flatten 
set of packages. This is done by BJam already the same, but at 
compilation/build step, and without the burden of the extra management 
of packages (update upstream Y for instance, when Y can be a set of many 
packages, and obviously in a confined, repeatable and isolated 
development environment). But maybe you think of something else.

To me this is a highly non trivial task to do with CMake, and ends up in 
half backed solutions like ROS/Catkin 
(http://wiki.ros.org/catkin/conceptual_overview), which is really not 
CMake and is just making things harder for everyone.

- I can continue... such as targets subset selection. It is doable with 
CMake with, "I think" some umbrella projects, but again this is hard to 
maintain and requires a high level orchestration. Only for the tests for 
instance: suppose I do not want to compile them in my first step, and 
then I change my mind, I want to run a subset of them. What I also want 
is not wasting my time in waiting for a billion of files to compile, I 
just want the minimal compilation. So it comes to my mind that 
EXCLUDE_FROM_ALL might be used, but when I run ctest -R something*, I 
get an error... Maybe you know a good way of doing that in cmake?

> Finally, for boost, it could provide some high-level cmake functions so all of these things can happen consistently across libraries.

Sure. Or ... BJam should be given some more care and visibility, like a 
GSoC (bis) track?