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

Subject: Re: [boost] [EXTERNAL] Request for a "Policy Review"regarding 'CMakeLists.txt'
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-05-20 11:38:37

On 5/20/16 6:25 AM, Peter Dimov wrote:
> alex wrote:
>> > But if boost can’t make this trivial change to better support cmake,
>> > then it would be hopeless for future changes in boost for better
>> cmake > support.
>>
>> I don't really have a stake in this, but I think this is the reason
>> why this discussion is so awkward. It seems that 'CMakeLists.txt' is
>> seen by both opponents and proponents as a foot in the door for future
>> changes in Boost for better cmake support.
>
> Yes.
Yes again.
>
> Incidentally, and ironically, a CMake-ified Boost that duplicates our
> current Boost.Build setup would probably have its CMakeLists.txt files
> in build/, so that the top level can glob for build/CMakeLists.txt.
> Globbing for CMakeLists.txt finds too many subdirectories you don't
> really want to find. (And status/CMakeLists.txt will glob for
> test/CMakeLists.txt, perhaps.)

At least the way I use CMake this isn't a problem. I just point the GUI 
to the top CMakeLists.txt file whereever it happens to be. Simple as pie.

>> I can understand existing library maintainers being worried about
>> having to support cmake in the future (or risk looking arcane).
>
> Speaking for myself, I have no problem at all with supporting cmake at
> some point in the future, if necessary.

Right.

If more new library authors support it, and more users expect it, And 
standard customs evolve and perhaps a CMake Template for making scripts 
gets written and perhaps someone writes a document on CMake customs and 
best practices with regards to Boost, it will become a defacto 
requirement.  QuickBook has a similar history.  Having or not having a 
CMakeLists.txt file at the library root won't matter either way.

Robert Ramey