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

Subject: Re: [boost] [EXTERNAL] Request for a "Policy Review" regarding 'CMakeLists.txt'
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-05-19 20:56:55

On Thursday, May 19, 2016 at 7:30:07 PM UTC-5, Gavin Lambert wrote:
>
> On 20/05/2016 10:55, Paul Fultz II wrote: 
> >> Nobody said there is one, people rather said there is no technical 
> issue 
> >> in having your CMakeLists.txt in ./build or ./cmake or ./anyothersubdir 
> >> (something that you seems to omit quite often). 
> > 
> > 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. 
>
> This is a defect in cget, if it does not expect/allow CMakeLists to be 
> in a subdirectory.  They are never supposed to be in the output 
> directory of cmake (which defaults to the current directory), after all, 
> so you always have to tell cmake where to find them. 
>

'hana/build' is not the output directory, it is the directory where the
guidelines says to put the cmake file. It is confusing, I know.

Also, there is no defect in cget. cget just calls cmake on whatever 
directory
you give it. cget can also unpack a tar file and call cmake on that as well.
It can also download a file, untar it, and call cmake on that as well. 

If a library decides to hide its cmake file, then the user will need to
manually download and untar the file and call cget on whatever directory 
your
cmake file is hidden in. This is not a defect of cget. If a library has 
chosen
to hide its cmake files, then its very difficult for the tool to known what
cmake is the entry point. Instead, it requires the user to find where the
cmake is supposed to be at from either the readme or the documentation, and
then explicitly call out to the tool with the directory where the cmake is
hidden.

Of course, the disadvantage of this approach is that the tool cannot
automatically download dependencies, which is one reason among many why I am
opposed to hiding cmake files in boost.