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
>>>>> say on GitHub.
>>>>> Forcing CMakeLists.txt at a different place would make Boost the odd
>>>> out if you look at CMake conventions. It's not what you would expect as
>>>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk