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

On Apr 13, 2016, at 4:00 PM, Robert Ramey wrote:

On 4/13/16 1:08 PM, Stephen Kelly wrote:

...

boost@glenstark.net wrote:

...

what to do now?

http://thread.gmane.org/gmane.comp.lib.boost.build/27386

I found this to be interesting. I've made a CMake directory as part of the serialization library which I use for building the IDE files which aid in library build and testing. It can be found in the boost serialization module of boost. My motivation is to take a step in the direction whereby users desirous of using the serialization library could do so without having to use boost build. I envision a user being able to clone the serialization subdirectory, add it "somewhere" to his project and have it "imported”.

The CMakeLists.txt file should be in the top-level directory. 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. 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 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).

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 with 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.

Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost