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

Subject: Re: [boost] [CMake] what to do now?
From: Rob Stewart (rstewart_at_[hidden])
Date: 2016-04-16 06:37:18

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.

>>>> however, this won't work for serialization(and won't ever).
>>>
>>> Hmmmm - why not?
>>
>> Because it doesn't have a CMakeLists.txt in the root directory.
>
>LOL - well it wouldn't be a big deal to add a CMakeLists.txt file
>with 3 add_directory statments in it.  And I really wouldn't object to 
>it if I were to become convinced that it had a real benefit.

CMake-related tooling assumes a top-level list file. Deviating from that either breaks tools or requires adding rarely needed options to deal with an unconventional layout.

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.)

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.

My point is that a top-level list file can be generated, and choosing what and how to build and run need not always conform to CMake conventions. However, doing so means one needs additional scripting and, unfortunately, CMake-related tools know nothing of the added scripts.

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, or library authors/maintainers individually.

___
Rob

(Sent from my portable computation engine)