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

[Nikita Popov via llvm-dev]

On Wed, Mar 25, 2020 at 5:01 PM Tom Stellard via llvm-dev <
llvm-dev at lists.llvm.org> 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.
>

I think the relevant metric here needs to be "which version is available on
current LTS distros", and not "how old is the release". The current cmake
version I have on Ubuntu 18.04 is cmake 3.10.2, so I personally would be
happy with a bump to that version, but not something newer. People using
other distributions probably have other considerations. If someone wants to
perform a cmake version bump, I believe the first step would be to gather
what the cmake version availability across distros looks like right now, so
an informed decision can be made.

Regards,
Nikita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200325/5916c18d/attachment.html>