[llvm-dev] Bumping the CMake requirement for libc++ and libc++abi

Wed Mar 25 09:50:08 PDT 2020

The next Ubuntu LTS release 20.04 will be available April 23.

https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule

That release will have cmake version 3.16.3.

https://packages.ubuntu.com/search?suite=focal&arch=any&searchon=all&keywords=cmake

It may take 6 months or so for the LTS users to upgrade in that the 
automatic update without reinstalling will not be ready for a while. 
Some people can create a 20.04 VM as soon as the release is available.

Neil Nelson

On 3/25/20 10:33 AM, Pavel Labath via llvm-dev wrote:
> If we're going to be updating the cmake version requirements llvm-wide
> (and in particular, if we're going to make a policy out of that), I
> think that should be done in a new RFC thread with an appropriate
> subject -- people may not notice this discussion because they don't
> follow libc++ and ignore any discussions relating to it.
>
> As for the policy itself, I can't say I am fan of automatically bumping
> version requirements, just because. A similar idea was proposed when we
> were bumping the compiler versions, and was eventually rejected in favor
> of the process described at
> <https://llvm.org/docs/DeveloperPolicy.html#updating-toolchain-requirements>.
> The current process involves proposing a specific version and discussing
> the trade-offs implied by it.
>
> Now, bumping the cmake version is not as involved as bumping the
> compiler, but maybe it would be good if the process for doing it was
> similar? If for nothing else, then for consistency?
>
> regards,
> Pavel
>
>
>
> On 25/03/2020 17:04, Louis Dionne via llvm-dev wrote:
>>
>>> On Mar 25, 2020, at 12:00, Tom Stellard <tstellar at redhat.com
>>> <mailto:tstellar at redhat.com>> wrote:
>>>
>>> On 03/25/2020 06:20 AM, Louis Dionne wrote:
>>>>
>>>>> On Mar 25, 2020, at 00:47, Tom Stellard <tstellar at redhat.com
>>>>> <mailto:tstellar at redhat.com>> wrote:
>>>>>
>>>>> On 03/24/2020 09:00 PM, Petr Hosek via llvm-dev wrote:
>>>>>> In October, there was a discussion about updating CMake to 3.15:
>>>>>> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136295.html.
>>>>>> No decision was made, but maybe we should revisit that proposal? If
>>>>>> we're going to require a newer version of CMake for some
>>>>>> subprojects, I'd prefer to bump the minimum CMake version for all
>>>>>> of LLVM.
>>>> My personal opinion is that there's a tendency to view all
>>>> subprojects under the LLVM umbrella as a single, monolithic project.
>>>> That leads to the desire to make decisions for the whole project,
>>>> which is often difficult, as opposed to making the right decision for
>>>> each subproject, which is often easier. This results on subprojects
>>>> being blocked from doing the right thing for them, like we've seen
>>>> happen for pre-commit CI. But that's a much larger (non-technical)
>>>> discussion than the scope of a simple CMake version bump.
>>>>
>>>> Let's try to bump CMake for all of LLVM and see how that goes.
>>>>
>>>>> Yes, I agree we should bump the version for all of LLVM, but I don't
>>>>> think we should bump the version without a long-term cmake usage plan.
>>>>> e.g. something like: After every release branch, we bump the cmake
>>>>> version
>>>>> to whatever version of cmake is X months old.
>>>>>
>>>>> I think the concern that this was our one chance to bump the CMake
>>>>> version
>>>>> led to the choice of 3.15 as the next version, which would be too
>>>>> new for some Linux distros.
>>>>> I think if we had a planned upgrade path, it would be easier for
>>>>> those of us that
>>>>> want something really new to settle on a release that is a little
>>>>> bit older.
>>>> Ok, how about the following policy:
>>>>
>>>>   After every release branch, we bump the CMake version to whatever
>>>> version of CMake is 12 months old.
>>>>
>>>> This is simple, straightforward, and it gives a full year of old
>>>> CMakes being supported. If we did this right now, this would take us
>>>> to CMake 3.14.0, released around March 14th, 2019
>>>> (https://github.com/Kitware/CMake/releases/tag/v3.14.0). I believe
>>>> the expectation should be that recent CMakes are upgraded using some
>>>> package manager or download from the site -- we can't really expect
>>>> the CMake version to be the one provided by the system, because that
>>>> is either non-existent or very old on most Linux distributions
>>>> AFAICT. Fortunately, installing a new CMake is incredibly easy.
>>>>
>>>> Is everybody OK with the above policy? What would be the preferred
>>>> place to document it?
>>>>
>>> 12 months is fine with me.
>>>
>>> I'm not sure the best place to document the policy.  Some suggestions
>>> are here:
>>> https://llvm.org/docs/CMake.html or in the Programmer's manual.
>> Okay, so assuming nobody objects to this, the process would then be:
>> - I put up a Phabricator review updating the documentation and the
>> `cmake_minimum_required` fields for (all?) LLVM projects I can find.
>> - I wait for <some amount of time> before committing the change for
>> build bot owners to update their CMake
>> - I commit the change -- at that point using a too-old CMake will error
>> out and we can point any remaining failing bot to the policy
>>
>> Does that sound like a reasonable plan? What should be the <some amount
>> of time>? I'd suggest something like two weeks to give folks ample time
>> to update builders.
>>
>> Louis
>>
>>> -Tom
>>>
>>>> Cheers,
>>>> Louis
>>>>
>>>>>> On Tue, Mar 24, 2020 at 8:11 PM Louis Dionne via llvm-dev
>>>>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>>>> <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>>>>
>>>>>>    Hi,
>>>>>>
>>>>>>    The minimum CMake version currently advertised for libc++ and
>>>>>> libc++abi is currently 3.4.3. I think the oldest version of CMake
>>>>>> actually being tested on any builder is 3.7.0, so advertising 3.4.3
>>>>>> is somewhat of a lie (I'm pretty sure we're using features that
>>>>>> require a more recent version already). However, we do need to bump
>>>>>> it to 3.8.0 at least because CMake 3.7 doesn't know about C++17 in
>>>>>> its compilation features, and we'll need that to build libc++
>>>>>> properly going forward. This will mean for bot owners:
>>>>>>    1. They need to upgrade CMake on the builders to at least 3.8.0
>>>>>> (which is really easy), or
>>>>>>    2. they can disable processing of libc++ and libc++abi's CMake
>>>>>> files by making sure they do not appear in LLVM_ENABLE_PROJECTS
>>>>>>
>>>>>>    Any objections?
>>>>>>
>>>>>>    Cheers,
>>>>>>    Louis
>>>>>>
>>>>>>    _______________________________________________
>>>>>>    LLVM Developers mailing list
>>>>>>    llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>>>> <mailto:llvm-dev at lists.llvm.org>
>>>>>>    https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200325/786c7988/attachment.html>