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

Subject: Re: [boost] [CMake] what to do now?
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-04-14 08:52:52

> On Apr 13, 2016, at 11:55 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> 
> On 4/13/16 4:47 PM, P F wrote:
>> 
>>> On Apr 13, 2016, at 6:00 PM, Robert Ramey <ramey_at_[hidden]> wrote:
>>> 
>>> 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.
>> 
>> The Fit library has the cmake at the top-level and it doesn’t have cmake files sprinkled 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.
>> 
>> Breaking the convention makes it much more intrusive, since a fork is needed to put the cmake where its expected by other tools.
>> 
>>> 
>>> 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.
>> 
>> That may work for development, but its pretty horrible for users to do this to install the latest serialization library.
> 
> I'm not seeing a problem here.
> 
> Plus, with the cycles, boost is still not tested correctly.
> 
> Boost or the serialization library?  Users who want to test he serialization library can do it this way.  Those who want to test all of boost can't do it now with CMake anyway.  Then there is the question of dependencies which we discussed some time ago without being able to arrive at a consensus.

If another library provided a cmake as well, then this process gets complicated to build and test all the libraries. 

> 
> In summary, the usage of CMake is currently up to the individual library so it doesn't really need to follow other conventions.  I generally agree that following convention is a good thing. But I'm not familiar with CMake to know that there actually is a convention nor what the rationale for such a convention might be.
> 
>> 
>>> 
>>> 
>>>>> 
>>>>> 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.
>> 
>> Yea, I usually do this by hand, the point is to avoided this copying and pasting.
> 
> So, we could make it a lot easier for users just by including the above boiler plate?  In other words we wouldn't have to muck with boost build at all?  I could buy that.

Of course it can make it a lot easier for developers, but I don’t think thats what needed to convince boost to move to cmake.

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