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

Thu Jul 16 19:48:25 PDT 2020

On 17 Jul 2020, at 03:33, Mehdi AMINI <joker.eph at gmail.com> wrote:
> On Thu, Jul 16, 2020 at 6:57 PM Jessica Clarke via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> I wouldn't encourage using the apt repo. The whole PPA/random apt repo thing is bad security practice, as any package being installed has full root access to the system during its maintscripts. PPAs are marginally better since they are at least hosted on launchpad.net <http://launchpad.net/> and so have some guarantees over the infrastructure, but you shouldn't trust a random apt repo out there has good security practices with its signing key (even if you trust the authors of the software). It is a shame Ubuntu's backports are basically non-existent (I've tried to get backports uploaded for *my own* packages before and they just sit in the queue), as I'd be completely fine with saying "just enable bionic-backports and install from there". But the world on Ubuntu is dysfunctional there, unlike Debian's sane world. Maybe I can talk to some Ubuntu developers and see if they can force a backport through.
> 
> Also, please bear in mind the distro maintenance story. Firefox needs regular security updates, and depends on Rust, which itself depends on LLVM. Given the fast-moving nature of Rust, it may well be that Ubuntu needs to update to a newer Rust to support the latest Firefox ESR, and that that Rust depends on LLVM 12+, forcing them to also have to update CMake. I don't think dependency bumps of any kind should be taken lightly when LLVM is becoming such a crucial part of modern systems.
> 
> I am not super familiar with this level of details in the package build system, but CMake isn't a "public" dependency of LLVM: it is needed to build LLVM but then the resulting package does not depend on CMake. As such a dedicated version of CMake can be bootstrapped and stay private in the build-directory (cf the revision I posted separately) of LLVM when building the package itself.

That's a non-starter for distributions. All dependencies used in any official builds must come from the archive (and the same one that LLVM is in; you can't have a random special one off to the side). And they are very against vendoring copies of code as it becomes a maintenance nightmare. As far as distributions are concerned, "needs X to build" and "needs X to use" amount to basically the same requirements.

Jess

>> On 17 Jul 2020, at 02:35, Mehdi AMINI <joker.eph at gmail.com <mailto:joker.eph at gmail.com>> wrote:
>> 
>> What about helping the user: https://reviews.llvm.org/D83995 <https://reviews.llvm.org/D83995> ?
>> (can also improve the detection to point at the apt repo on Ubuntu if needed)
>> 
>> -- 
>> Mehdi
>> 
>> 
>> On Thu, Jul 16, 2020 at 6:21 PM James Y Knight via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 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/ <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 <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 <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 <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 <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/33d2fdff/attachment.html>