Re: [boost] [EXTERNAL] Request for a "Policy Review" regarding 'CMakeLists.txt'

Subject: Re: [boost] [EXTERNAL] Request for a "Policy Review" regarding 'CMakeLists.txt'
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2016-05-21 16:56:59

On 05/20/2016 12:55 AM, Paul Fultz II wrote:
> Yes there is a technical as well as a usability issue with hiding the cmake
> file in some directory. This causes problems with other tools. You will no
> longer be able to install a boost library with `cget install boostorg/hana`.
> Instead the user will have to manually download the repo, unpack the
> archive,
> and then do `cget install hana/build`. I find that unacceptable.
>
> Library authors who support cmake  do not want their support treated as a
> second-class citizen.

This thread is the first time I hear about cget. Is this some official 
CMake thingy? Looks like it is not. Having your root CMakeLists.txt in a 
seperate build directory does *not* make it a second class citizen. 
Since cget is your tool, couldn't you just add the functionality that 
boosts directory layout is supported? Sorry if I sound dense here, but 
this discussion seems to circle around the fact that *your* tool can not 
support this directory layout. CMake itself, and any other tool I know 
of is pretty agnostic to where the actual CMakeLists.txt of a project 
actually resides. I could even provide a completely out of tree 
CMakeLists.txt that will build you boost in a top level directory, 
create you solution files and whatnot that will display you all of 
boost's sources without even touching or forking any official boost 
repository.

What's the big deal here?