[llvm-dev] Upgrading LLVM's minimum required CMake version
Mehdi AMINI via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 16 19:33:52 PDT 2020
On Thu, Jul 16, 2020 at 6:57 PM Jessica Clarke via llvm-dev <
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 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.
--
Mehdi
>
> Jess
>
> On 17 Jul 2020, at 02:35, Mehdi AMINI <joker.eph at gmail.com> wrote:
>
> What about helping the user: 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> 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/).
>>
>>
>> On Thu, Jul 16, 2020 at 8:05 PM Jessica Clarke via llvm-dev <
>> 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> wrote:
>>> >> On Apr 8, 2020, at 13:06, Louis Dionne <ldionne at apple.com> wrote:
>>> >>> On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev <
>>> 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
>>> >>
>>> >> 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.
>>> >
>>> > 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. 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
>>> 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/20200716/9c978a27/attachment.html>
More information about the llvm-dev
mailing list