[llvm-dev] Upgrading LLVM's minimum required CMake version

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Fri Jul 17 09:29:28 PDT 2020


+1 to Medhi's point here.

Using a standalone cmake is easy; using a customer toolchain is not.

Philip

On 7/16/20 6:38 PM, Mehdi AMINI via llvm-dev wrote:
> While on the surface they seem like very similar dependencies, I see 
> quite a difference in terms of size and complexity in order to 
> download and bootstrap gcc vs CMake though. I could envision 
> bootstrapping CMake as part of my buildbot, but I likely wouldn't do 
> it as easily with gcc for instance.
>
> Also the requirement on the compiler version may apply transitively to 
> users of LLVM (through header inclusion) while the CMake version is 
> very local to LLVM.
>
> -- 
> Mehdi
>
>
> On Thu, Jul 16, 2020 at 6:25 PM Keane, Erich via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     It is curious to me that we had so much push back about moving
>     host-compiler versions, yet so little on the cmake versions.  In
>     my opinion, we need to have a unified ‘dependency age’ policy.
>     Cmake 3.13.4 was released about 18 months ago, so unless we’re
>     willing to move our GCC version to 8.3 JUST as easily, this seems
>     like a horrific double standard.
>
>     *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org
>     <mailto:llvm-dev-bounces at lists.llvm.org>> *On Behalf Of *James Y
>     Knight via llvm-dev
>     *Sent:* Thursday, July 16, 2020 6:21 PM
>     *To:* Jessica Clarke <jrtc27 at jrtc27.com <mailto:jrtc27 at jrtc27.com>>
>     *Cc:* llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     *Subject:* Re: [llvm-dev] Upgrading LLVM's minimum required CMake
>     version
>
>     Please, no more waiting on CMake versions in distro LTS releases.
>     We have been /way/ too conservative already, waiting this long.
>
>     Downloading and building a local copy of cmake is trivial. You
>     don't even need to install it. Anyone who is developing and
>     building LLVM can definitely manage it. Not only that, kitware
>     even has an official apt repository -- you can install a deb if
>     installing that seems easier for you (https://apt.kitware.com/).
>
>     On Thu, Jul 16, 2020 at 8:05 PM Jessica Clarke via llvm-dev
>     <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>         On 30 Jun 2020, at 16:04, Louis Dionne via llvm-dev
>         <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>         >> On Apr 8, 2020, at 13:06, Louis Dionne <ldionne at apple.com
>         <mailto:ldionne at apple.com>> wrote:
>         >>> On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev
>         <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>         >>>
>         >>> Okay, so we've had some discussion on this thread, and
>         although some people (including me) would like a more
>         aggressive policy, I believe the following will not get any
>         objection (based on the thread). On April 23rd 2020, Ubuntu
>         20.04 LTS will ship with CMake 3.16.x. This will make the
>         lower bound for LTS distributions be 3.13.4, and so I suggest
>         we upgrade to that. Here's a proposed process:
>         >>>
>         >>> 1. Immediately add a CMake warning in
>         <root>/llvm/CMakeLists.txt saying that CMake 3.13.4 will be
>         the new minimum version starting with LLVM 12.0.0, and
>         mentioning the versions used in various LTSes.
>         >>> 2. Immediately send a courtesy heads-up email to all
>         build-bot owners telling them about the upcoming change.
>         >>> 3. Right after we branch off the release branch for LLVM
>         11.0.0 (the next one), make the minimum CMake version required
>         be 3.13.4.
>         >>> 4. Iterate on (3) until all bots are migrated.
>         >>> 5. Send a message to the list saying the bump is complete.
>         At that time, projects are free to start using features from
>         3.13.4.
>         >>>
>         >>> Unless someone else absolutely wants to bite the bullet, I
>         volunteer to do the above steps.
>         >>
>         >> Ok, so the thread has kept going, but AFAICT all the
>         discussion is about a policy for "automatic" upgrades. So I've
>         went ahead and did the first two steps of the above algorithm:
>         >>
>         >> (1) Review at https://reviews.llvm.org/D77740
>         >> (2) Email sent to the owners of all build slaves listed on
>         http://lab.llvm.org:8011/buildslaves
>         <http://lab.llvm.org:8011/buildslaves>
>         >>
>         >> Just to reiterate, this means that as soon as we branch
>         LLVM 11.0.0 (the NEXT release), CMake 3.13.4 will be the
>         minimum required version.
>         >
>         > Hi,
>         >
>         > Just a heads up that about two weeks from now, we should be
>         branching for the LLVM 11.0.0 release. Right after we branch,
>         I will implement steps (3) and (4) of the algorithm described
>         above, which is to make the minimum CMake version required be
>         3.13.4. I will do this by checking-in this patch:
>         https://reviews.llvm.org/D78646 <https://reviews.llvm.org/D78646>.
>         >
>         > That patch will cause errors whenever the CMake version is
>         less than 3.13.4 -- I will then revert and re-apply this patch
>         until all build bots have upgraded to a sufficient CMake. The
>         patch was crafted to be minimal and revert-friendly. Note that
>         build bot owners have already been contacted in March and
>         pinged several times again for those who had not yet upgraded.
>         At this time, I think only 1-2 bots have not upgraded.
>         >
>         > Once everyone has upgraded, I will then apply this patch:
>         https://reviews.llvm.org/D78648
>         <https://reviews.llvm.org/D78648>. That patch marks the
>         minimum CMake version required as being 3.13.4 throughout the
>         monorepo in a slightly more invasive but definitive way. Once
>         that's all done, I'll report to the list that the version bump
>         is complete and we can all start using modern CMake features.
>         >
>         > Cheers,
>         > Louis
>
>         I missed this entire discussion but would like to chime in.
>         All of our department's machines run on Ubuntu 18.04 as
>         standard. I suspect the same is true across a large number of
>         organisations, as Ubuntu is a very popular distribution, and
>         the 18.04 LTS is still widely supported by most projects.
>         Whilst Ubuntu 20.04 has been released for a couple of months,
>         it's going to be a while until everyone has updated. In fact,
>         it isn't yet *officially supported* to upgrade from 18.04 to
>         20.04, as you have to wait for the first point release for
>         that, due in August. So as far as Canonical are concerned, if
>         you installed 18.04 LTS, you should still be on that, and
>         20.04 isn't ready for those people quite yet. That's a lot of
>         people affected who may not be following llvm-dev but will
>         suddenly find themselves in need of a custom CMake.
>
>         I would urge people to reconsider this move. I can see the
>         attraction of moving to the latest CMake, but we've managed
>         just fine so far, do we really need to move to the latest and
>         greatest right now? Ditching support for 18.04 in a year's
>         time would seem reasonable, but expecting everyone to have
>         moved over when it's not yet officially supported after just 3
>         months is not, and forcing everyone on those distributions to
>         build their own copy of CMake just for LLVM is annoying (sure,
>         I'm perfectly capable of doing it, but it's still a nuisance
>         that aggravates me). I'd suggest waiting at least until
>         20.04.1 has been released, so waiting until the next release
>         cycle would allow that and give around 6 months for people to
>         update, if not until the release cycle after that (though that
>         may be a harder pill for some members to swallow). But we
>         could at least bump to 3.10.2 in the meantime.
>
>         Jess
>
>         _______________________________________________
>         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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200717/8e7e0b05/attachment-0001.html>


More information about the llvm-dev mailing list