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

Subject: Re: [boost] Request for a "Policy Review" regarding 'CMakeLists.txt'
From: Thijs van den Berg (thijs_at_[hidden])
Date: 2016-05-17 10:11:02

On 17 May 2016 at 15:52, Vladimir Prus <vladimir.prus_at_[hidden]> wrote:

> On 17/05/2016 16:36, Thijs van den Berg wrote:
>
>> On 17 May 2016 at 15:29, Vladimir Prus <vladimir.prus_at_[hidden]> wrote:
>>
>> On 17/05/2016 16:16, Thijs van den Berg wrote:
>>>
>>> It is still a problem when somebody looks at sources of a particular
>>>
>>>> library,
>>>>> say on GitHub.
>>>>>
>>>>>
>>>>> Forcing CMakeLists.txt at a different place would make Boost the odd
>>>> one
>>>> out if you look at CMake conventions. It's not what you would expect as
>>>> a
>>>> CMake user, it's an unattractive restriction, and it's not a restriction
>>>> that's based on trying to solves something that's wouldn't work without
>>>> that restriction (e.g. a technical limitation)
>>>>
>>>>
>>> Everything above applies to Jamfiles.
>>>
>>> I don't see any burden this is going to put on Jamfile users. Developers
>>>
>> using Jamfiles are used to the way things are currently located on Boost
>> and that's not going to change if you add CMakeList.txt to the root.
>>
>
> May I ask how often do you edit Jamfiles? It do it somewhat often, and I
> do find having them in subdirectory to be a burden.
>
> My point is that you can keep doing so.. your Jamefiles editing will not
be affected if a CMakeLists.txt  get's added to the root.

You would need to point out a technical or rational reason to *not* stick
to the CMake conventions, and if there is one, then you might decide to not
stimulate CMake support at all because it would result in a unconventional
solution. Bjam is unconventional (it's not used outside of boost as said by
others), and the wish by many to better support CMake support is to break
from un-conventional burdens and offer more flexibility adn ease of use.