[llvm-dev] RFC: Updating to CMake 3.15.0

[David Blaikie via llvm-dev]

On Tue, Oct 29, 2019 at 10:28 AM Roman Lebedev via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> +1 to bumping cmake version and cleaning build system somewhat.
>
> On Tue, Oct 29, 2019 at 8:23 PM Tom Stellard via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > On 10/29/2019 10:10 AM, Chris Bieneman via llvm-dev wrote:
> > > At the LLVM Developer Meeting on October 23rd we held a CMake
> roundtable. One of the items we discussed was adopting a more regular
> timeline for CMake upgrades. During the roundtable there was overwhelming
> support for upgrading CMake, and support for treating CMake differently
> than how we treat upgrading host compilers.
> > >
> > > Historically we've taken into account recent versions of Visual
> Studio, Xcode and Linux distribution long term support packages when
> deciding what CMake version to require. While this does work, it has held
> us to old versions of CMake for long periods of time.
> > >
> > > During the roundtable we discussed that the amount of effort involved
> in updating to a modern CMake is more or less the same regardless of what
> version we choose. We believe this to be true because most OS package
> managers have older versions, like the Ubuntu 18.04 LTS which has CMake
> 3.10.2 which was released January 18, 2018. Additionally CMake.org provides
> binary and source downloads, and building CMake from source has lower
> system requirements than LLVM and is very simple.
> > >
> > > With all of this in mind at the roundtable we decided to propose
> raising the minimum required CMake version for all LLVM sub-projects to
> 3.15.0. Assuming there are no objections to this proposal, I propose a
> cut-over date of December 2, 2019.
> > >
> >
> > Will users of the CMake export files generated by LLVM also need to use
> 3.15.0 or
> > is it possibly to have the export files require an older version?
> >
> > The 10.0 branchpoint will be in early January, I think it would be better
> > to wait until after the branch.  Mainly because that doesn't give us a
> > lot of time to actually take advantage of the new features  in 3.15.0
> before the
> > branch, so I don't see much benefit in switching over at that date.
> >
> > I think we should also decide on a long-term plan for CMake requirements.
> > If the conclusion is that users should be able to handle using the latest
> > (3.15.0) version of CMake, maybe we should just plan to always up-date
> to the
> > latest version in trunk after each release branch is created.
> Would it please be possible to have some reasonably sane
> dependency versioning policy?


I'm not sure "sane" captures the nuance of your position - only suggests
that Tom's suggestion of upgrading to the latest release is "insane"?

What is it you'd like to avoid or that you find important/valuable about a
one year old version of CMake, for instance? It means users have to update
their CMake as frequently (since it doesn't skip versions) - but allows
some users to get this based on their distributions release, rather than
having to do it manually/explicitly?


> Even debian sid only has 3.13.4-1.
> How about accepting/requiring version which is at least 1 year old?
> That would incidentally, result in requiring cmake v3.13
>
> > -Tom
> Roman
>
> > > Thanks,
> > > -Chris
> > > _______________________________________________
> > > 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
> _______________________________________________
> 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/20191029/69df05fe/attachment.html>