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 13:55:54

On Thursday, May 19, 2016 at 11:18:44 AM UTC-5, Belcourt, Kenneth wrote:
>
>
> > On May 18, 2016, at 12:52 PM, Vladimir Prus <vladim..._at_[hidden] 
> <javascript:>> wrote: 
> > 
> > On 18/05/2016 20:20, Paul Fultz II wrote: 
> > 
> >>> The original post on the thread stated: 
> >>> 
> >>> "We recommend and propose that the Boost Guidelines are modified to 
> >>> allow library authors, at their own discretion, to include a 
> >>> 'CMakeLists.txt' file in their library's top-level directory." 
> >>> 
> >>> Leave aside the fact this as far as I know this has never been 
> >>> prohibited.  It seems that the request is that the stated policy 
> >>> incorporate the above text and that no one has actually argued against 
> >>> this. It seems to me that you're getting exactly what been asked for. 
> >> 
> >> 
> >> Rene has made it clear that it was prohibited by the guidelines, and 
> >> Vladimir is opposed to it. 
> > 
> > I am specifically opposed to permitting cmake stuff at root level of 
> > a library while requiring that Boost.Build files are in the 'build' 
> directory. 
> > This objection can be addressed by either allowing all of that at the 
> root 
> > (not really facetious suggestion), or by requiring that all build files 
> > be under 'build' directory - which has the advantage of actually 
> scaling, 
> > and apparently is possible with all possible build systems. In the 
> latter 
> > case the guidelines might be amended to say that library author can add 
> > additional build systems support, though in practice we already have 
> makefiles 
> > and VS solutions and what not. 
>
> I’d like to see the CMake files in the same locations as the Jamfiles so 
> we have a consistent layout for build and test across Boost. 
>

I am opposed to this, and what we are proposing is allowing Cmake at the 
top-level. I have yet to see a technical issue with this. It is true that 
the cmake is more prominent then the bjam, but it is also better supported 
for those libraries that put CMakeLists.txt at the top-level. Boost.Hana, 
for example, has a more extensive test-suite when using cmake.