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

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

On 4/16/16 3:37 AM, Rob Stewart wrote:
> On April 16, 2016 12:59:18 AM EDT, Robert Ramey <ramey_at_[hidden]> wrote:
>>>
>>> Yes, of course, it will need to track test dependencies separate from
>>> the build dependencies. Cget already does that, I don't see
>>> that as problematic.
>>
>> I think you should think about it more.
>
> Paul's points are that cget presumes a top level CMakeLists.txt and that it can handle dependencies. Given those conditions, he claims that test dependencies can be handled. If you think otherwise, it would be helpful to point out what you think will fail.

We've gone through this several times.  The short version is that the 
depencies "depend" one what is its we're doing.  If I'm just building 
the library, there is one set of dependencies.  If I"m building and 
testing the library thre is a more extensive list of dependencies.  If 
I'm building just one app, there is a much smaller number of 
dependencies.  The problem is sufficiently complex that I don't believe 
that it's possible to make a straightforward tool can actually do 
determine what the dependcies actually are.

Note that I'm not even touching on the issue of possible circular 
dependencies which is a whole 'nother can of worms.

> CMake-related tooling assumes a top-level list file.

I'm not sure exactly what you're refering to here.  I run 
CMake/CTest/CDash without a top level directory.  I think its a 
convention - not a requirement.  I've said that if it IS necessary, a 
simple 5-10 file would bridge the gap in any case.

Deviating from that either breaks tools or requires adding rarely needed 
options to deal with an unconventional layout.

I'm not seeing this either.

> IME, CMake is both helpful and frustrating. As Paul noted, supporting multiple platforms is managed via multiple out-of-source-tree build directories. Besides keeping platform-specific artifacts separate, that has the advantage of allowing the use of local disk even when the source tree is on the network. It also has the disadvantage of having to dance around in multiple trees to find source files and build artifacts, and the inability to build from anywhere within the source or build trees. (I could list more, but that's enough for my purpose.)

All of the above is true - but unrelated to any requirement for a 
library root level CMakeLists.txt.

> To address these and other issues, I've found it necessary to use a script to manage CMake. That script generates a top-level CMakeLists.txt, if there isn't one, creates a build directory appropriate for the host platform and selected compiler, cd's to that directory, and issues the appropriate cmake command. The script also finds its way between the two trees, using breadcrumbs, which allows issuing the build command from anywhere in the two trees.

This is what I've hoped to avoid:  Addressing some problem in one tool 
by creating a new tool on top of it.  It's a symptom that more thought 
needs to be invested.

> Paul and Louis are arguing in favor not only of convention, to avoid user surprises, but of enabling cget, Travis, Appveyor, and other tools that will help Boost generally,

Honestly, I don't know enough about how these work to add much here.

> or library authors/maintainers individually.

If library authors/maintainers want to do it to their own libraries 
there's no problem.  The problem comes up when one group of authors 
want's all the others to do something.

Robert Ramey