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

Subject: Re: [boost] Request for a "Policy Review" regarding 'CMakeLists.txt'
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-05-18 21:31:48

On 18/05/2016 12:31, Paul Fultz II wrote:
> On Tuesday, May 17, 2016 at 7:07:44 PM UTC-5, Peter Dimov wrote:
>> Paul Fultz II wrote:
>>
>>> The tool doesn't look for CMakeLists.txt at all. It just calls cmake on
>>> the library. If you want it to search in another location, its best to
>>> update cmake to do that.
>>
>> cmake takes the directory as an argument, so it would make absolutely no
>> sense for it to search. If you want cmake to look for CMakeLists.txt
>> somewhere, you pass that somewhere to it.
>
> That is true, but considering putting a cmake in another directory is first,
> quite rare, and also non-conventional. Therefore, it is difficult to decide
> what directory should be searched, and in what order the search to happen.
> Its much simpler to just put the cmake file where it is expected to be.

My experience is admittedly limited (most projects I use build using VS 
or autotools; cmake is comparatively rare), but most that I have seen 
either put the CMakeLists.txt file in the root or in a cmake subdirectory.

More importantly, however, is that you *never* run cmake in the same 
directory as the CMakeLists.txt file, so you never run it without 
parameters.  Without exception (in my limited experience) the 
instructions are to create and switch to a build subdirectory and run 
cmake in that, pointing it at the other directory (typically .. or 
../cmake) that actually contains the CMakeLists.txt.

(This is important because CMake lacks the ability to clean up after 
itself, unlike autotools, so you need to keep it segregated from the 
original source.)

So I don't see why it'd be weird for Boost to put the CMakeLists.txt in 
cmake/ or build/.