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

[Hubert Tong via libcxx-dev]

On Wed, Mar 25, 2020 at 12:05 PM Louis Dionne via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Mar 25, 2020, at 12:00, Tom Stellard <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> 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
>
The build compiler and library version updating involved reverting the
change when it is known that bots are failing and recommitting when known
issues are resolved. It may take several rounds to flush everything out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20200325/1d9f83bc/attachment-0001.html>