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

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

On 4/15/16 10:13 AM, Paul Fultz II wrote:
>
>
> On Thursday, April 14, 2016 at 8:47:45 PM UTC-5, Robert Ramey wrote:
>>
>> On 4/14/16 4:02 PM, Andrey Semashev wrote:
>>
>>> I think you misunderstood me. You can build sources, docs and tests
>>> separately. You can place CMakeLists.txt at the places where Jamfiles
>>> currently are. Each of these CMakeLists.txt would declare their own
>>> project and could be independent from others.
>>>
>>> However, the common practice is a bit different. There is typically a
>>> single root CMakeLists.txt, which defines a project and then includes a
>>> number of nested CMakeLists.txt. The nested CMakeLists.txt may or may
>>> not define their projects, that doesn't really matter if you invoke
>>> cmake with the root CMakeLists.txt because you're generating makefiles
>>> for the whole tree in this case. You can also build targets selectively
>>> in this case.
>>
>> My understanding is quite different.
>>
>> In each directory one has a CMakeLists.txt file.  This would closely
>> correspond to current boost practice.
>>
>> In addition in the parent directory one creates a CMakeLists.txt
>> directory.  It's primary function is to factor common CMake commands
>> corresponding to the child directories.  It includes a statement
>> add_directory(<child directory name>) for each subdirectory.
>> Then when you CMake the parent all the children are "CMaked" after
>> having processed the common code in the parent.  As it stands this makes
>> sense.  But if you include common CMake commands in the parent you won't
>> be able to run CMake on the subdirectories.  So if you want to that,
>> just refrain from factoring common code in the parent directory CMake.
>> I believe that CMake has an "include" facility so you could have it both
>> ways - start from the parent or the children.
>>
>
> Unifying common utilities is not the only reason to have a top-level
> directory. The other reason is so users don't have to create multiple build
> directories.

<snip>

Right

<snip>

So CMake and boost build ecourage CMake files in each subdirectory.  Agreed?

The only question is whether or not a CMakeList.txt file must exist in 
the parent/library directory.

My answer is ... it depends.

If I want to just build part of the library - like the docs it's very 
convenient to just create a local CMake project (in a separate directory 
tree) from <library>/docs/boostbook.  Similarly, if I want to just build 
the library without testing, it's convenient to just create a local 
CMake project which does this.  If you want test using this approach, 
you'll create a separate build of the library which would be redundant. 
  But it's not the end of the world.  I'm guessing that boost developers 
would not be uncomfortable with all this.

Now boost users.

Moving to boost users - some might find it convenient to have a library 
level CMakeList.txt file which includes add-directory.  It it included 
much else, it might break the ability to make part of the library.  I 
doubt most boost developers would be happy with this.

Actually, the CMake vision is that normal users install a "Package" 
which doesn't do any testing at all.  So they are not in this game.

On the other hand, If a library level CMakeLists.txt were required and 
the subdirectory level CMakeLists.txt could not function independently 
of this, then a user would have to build / test all or nothing. I've 
always wanted to require library users to run all the tests and post the 
results to a common place. CDash supposedly supports this, but has a 
number of issues.

To summarize, I believe that the only issue here is having a 
CMakeList.txt in the library root directory.  And I don't think it's a 
huge issue in the scheme of things.  My view would be that if someone 
want's to do it - OK - but I think they getting the benefit they think 
they are.

Robert Ramey