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

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

On 4/14/16 12:00 PM, Edward Diener wrote:
> On 4/14/2016 1:37 PM, Rene Rivera wrote:
>> On Thu, Apr 14, 2016 at 12:33 PM, Louis Dionne <ldionne.2_at_[hidden]>
>> wrote:
>>
>>>
>>> Don't overthink it. All I'm saying is that the Boost guidelines
>>> recommend
>>> that
>>> CMakeLists.txt should appear in $some_library/build/CMakeLists.txt,
>>> while I
>>> argue that current practice is to put it in
>>> $some_library/CMakeLists.txt.
>>>
>>
>> Just to be clear. It's not a recommendation. It's a requirement.
>
> Ideally could not one have a CMakeLists.txt file wherever there is
> currently a jamfile ? In the library's 'build' directory to build a
> non-header only library, in the library's 'doc' directory to build the
> docs, in the library's 'test' directory to run the tests etc.
>
> I don't know CMake but I assume it must be capable of having multiple
> CMakeLists.txt files for a library, or that a library's top-level
> CMakeLists.txt can refer to the individual CMakeLists.txt files in order
> to "build" all the library's components. If it is not capable of such
> stuff it certainly isn't usable by Boost.

Actually I believe that that is the way CMake is generally used.

When I got CMake working I put it all in one file in order to replicate 
the pattern I'm used to with boost build.  Now I'm beginning to think 
this might have been a mistake.  I wondering if we shouldn't have used:

<library name>
   include
     *.hpp
   src
     *.cpp
     Jamfile.v2
     CMakelist.txt
   doc
     html
     boostbook
       CMakeList.txt to convert boost book to html
     quikbook
       CMakeList.txt to convert quikbook to html
     ...
   test
     Jamfile.v2
     CMakelist.txt
     *.cpp
     *.pp
   ...

Note that not all libraries would have all components. This has the 
appeal of being regular.

> My personal problem with CMake is, while the language to use it is more
> understandable for me than 'jam', its doc is just as hard for me to
> understand as Boost Build if not even harder <g>. Mastering yet another
> build system which is documented mainly for those who already know what
> it is about is not my idea of programming fun.

This is the plague of "modern tools"  I spend more time 
working/configuring/etc the tools than I do actually writing source 
code.  It's a very depressing situation and no tool is immune.

Robert Ramey