Re: [boost] [CMake] what to do now?

Subject: Re: [boost] [CMake] what to do now?
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-04-13 19:00:08

On 4/13/16 3:37 PM, P F wrote:
>
> The CMakeLists.txt file should be in the top-level directory.

Hmmmm - says who?  I realize that this is the common way to do it.  But 
it ends up sprinkling CMakeList.txt files all over the place.  Doing it 
the way I've done makes supporting CMake much less intrusive and leaves 
the "footprint" of CMake support on par with build (boost build) easily 
permitting the user to select which he prefers.

Every library always provides the cmake file in the top-level directory. 
Plus, having in it the top-level directory allows it be easily installed 
using cget(ie `cget install boostorg/serialization`).

> Also, Boost.Hana and Boost.Compute provide a cmake build as well including pkg-config.
I'll take a look at these.
>
> Instead of trying to convert the all boost libraries to cmake, we could start to move to cmake little-by-little by first getting the core libraries using cmake.

I think that's what I'm proposing.

  I started writing a cmake(including testing using travis and appveyor) 
for Boost.Config here:
>
> https://github.com/pfultz2/config
>
> But then gave up when I realized that Boost.Config depends on Boost.Core which depends on Boost.Config. Before moving to modular cmake building, boost needs to get rid of its cyclic dependencies(especially in its core libraries). Cmake and pkg-config could still be provided for Boost.PP and maybe Boost.Predef(I am not sure if it depends on other libraries).

What I do is

a) clone boost to my local machine
b) build boost
c) use CMake to build my project. I use cmake find to find the boost 
headers and libraries.
d) now I have my project in CMake which works well the boost official 
library set.  I can create the IDE project
e) everything works great.

f) If I'm working on the serialization library, I treat it as if it's a 
user library - building/testng with CMake.  After I've got it working as 
I like, I run boost build just to make sure everything works correctly. 
  Bood build has the advantage that I can run all the combinations of 
static/share, debug/release, etc - autmatically and use library_status 
to build a test matrix of all combinations. With the serialization 
library, it's not unusual to have 2000 cells in this matrix.

FWIW - that's how I do it.

>>
>> A big problem I found with CMake is that it has the same problem that all these tools have.  It's not that obvious how to use it and takes a lot more investment of effort than one thinks it should.  On the other hand, CMake is almost universal so the investment is amortized across all the code you import.  So I resolved to plow through it.  The result is my CMake cheatsheet described in the Boost Library Incubator website.  After biting this bullet I've found CMake to be very useful especially since I like to you an IDE to develop an test code.  Since the serializetion library is huge library with lots of tests and modules, it's impractical to use an IDE without such a tool such as CMake.  I know I'm not using CMake to the very best advantage, and I'd like to see more information on making a canonical CMake file for a boost library such as boost serialization.  Ideally, users would be able to make use of such a file and this would motivate library authors to include such a file wi
 t
h their libraries.
>
> It would be nice if boost provided a cmake module(such as Boost.Cmake) which provided some utilities that would make building a boost library easier. It could provided utilities to help setup tests and install targets with pkg-config. Something like this:
>
> boost_package(
> PACKAGE
>      mylib
> DESCRIPTION
>      This is my library
> VERSION
>      1.0
> DEPENDS
>      filesystem thread
> SOURCES
>      lib/*.cpp
> HEADERS
>      include/*.hpp
> )
>
> And then additional utilities for adding tests that support valgrind and compile fail tests. I do this already for my projects, so it would be nice if there was an official module that contained these utilities. I thought about proposing something like this for boost, but I figured it would get rejected since the majority of libraries in boost use Boost.Build.

Hmmm - it seems that would be pretty easy to add by hand to the 
libraries I'm actually using.

Robert Ramey