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

On 4/16/16 3:37 AM, Rob Stewart wrote:

On April 16, 2016 12:59:18 AM EDT, Robert Ramey 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