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

Thu Apr 9 16:28:59 PDT 2020

On Thu, Apr 9, 2020 at 4:26 PM Philip Reames <listmail at philipreames.com>
wrote:

> Eric,
>
> I think you're commingling two points: "setup scripts" and "must support
> default toolchain".  I think it's important to keep them separate as, IMO,
> we should strongly resist the temptation to do the former, while the second
> is optional.
>
Sure, but... this discussion has hit both throughout it and it sounded like
you were also making commentary that way.

> Speaking personally, I'd be open to only supporting default configuration
> builds on a small subset of platforms. For instance, maybe *only* Ubuntu
> last LTS, Windows 10 latest, and MacOS latest.  Having to build a newer
> cmake doesn't seem like a huge hassle.
>
I'd really like "build cmake" to not be an option. "Install a release"
maybe, and Chris's points around the workflow in windows development (and
possibly things like osx in the future) are very compelling as well.

> We do want the setup to be straight forward for a broad class of
> recent-ish distros, but there's a difference between "instructions are
> simple and straight forward" and "works out of the box".
>

Agreed :)

-eric

> Philip
> On 4/9/20 4:18 PM, Eric Christopher wrote:
>
> FWIW I do very much agree here.
>
> Currently we specify a base set of compiler tools and cmake versions, but
> at this point if we follow the proposals mentioned by Philip, Chris, and
> Reid we need to actually give supported OS/Distro/Developer Tools versions
> in order to let people know base requirements. I'm not against specifying
> this, but I think we need consensus on how far back we're ok with "base
> system" or "LTS release" we're willing to support and the technical debt
> associated with such a support strategy :)
>
> Thoughts?
>
> -eric
>
> On Thu, Apr 9, 2020 at 4:13 PM Philip Reames via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I would be opposed to this proposal.  I've worked with build systems that
>> went this route before.  What happens is the script grows ever more
>> complicated, the person who wrote the script eventually leaves, and no one
>> knows how to build it outside of a particular frozen set of environments.
>> I've literally seen code bases die (i.e. no one wants to work on them,
>> eventual rewrite target) due to issues this can be traced solely back to
>> this decision.
>>
>> The fact we use standard build tools is a feature not a bug.  Let's not
>> "fix" our way into a much worse set of problems.
>>
>> Philip
>>
>> p.s. To be clear, I'm not stating an opinion on the original question of
>> whether building cmake from source was a reasonable expectation.
>> On 4/9/20 2:55 PM, Alexandre Ganea via llvm-dev wrote:
>>
>> Sorry if this was discussed,
>>
>>
>>
>> Why not have a *setup.sh*/*setup.bat*/*setup.exe* which could
>> download/install/setup everything we want, at the version we want, on a
>> vanilla system? Handle the cases described by Chris below? Why leave the
>> burden to the end-user?
>>
>>
>>
>> Currently, it’s not exactly trivial to setup everything for building &
>> running LLVM on Windows on a cloud VM if you want `ninja check-all` to pass
>> on
>> -DLLVM_ENABLE_PROJECTS=llvm;mlir;clang;lld;clang-tools-extra;compiler-rt;lldb.
>> There are many manuals steps, and often things that you forget (GnuWin32
>> FTW). On Ubuntu it is a bit easier, but still lots of trial and error.
>>
>>
>>
>> We use NuGet
>> <https://docs.microsoft.com/en-us/nuget/install-nuget-client-tools>
>> packages in our build system and for our developers, to ensure they always
>> have the right setup. Our games always build and use the toolings from the
>> .nugets, not the default installations on the machine. This guarantees
>> universal determinism everywhere and makes the developer setup a
>> *one-click-exe*. Setting up a similar thing for LLVM for different OSes
>> could be a bit more tricky, but nothing insurmountable?
>>
>>
>>
>>
>>
>> *De :* llvm-dev <llvm-dev-bounces at lists.llvm.org>
>> <llvm-dev-bounces at lists.llvm.org> *De la part de* Shoaib Meenai via
>> llvm-dev
>> *Envoyé :* April 9, 2020 4:26 PM
>> *À :* Reid Kleckner <rnk at google.com> <rnk at google.com>; James Y Knight
>> <jyknight at google.com> <jyknight at google.com>
>> *Cc :* llvm-dev at lists.llvm.org
>> *Objet :* Re: [llvm-dev] Upgrading LLVM's minimum required CMake version
>>
>>
>>
>> I agree that’s valuable, but then it’s also important to pin down exactly
>> what a “modern OS” is, and which ones we should keep in mind when we’re
>> considering e.g. which CMake versions are feasible. (The same applies even
>> more so to toolchain requirements, of course.)
>>
>>
>>
>> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Reid
>> Kleckner via llvm-dev <llvm-dev at lists.llvm.org>
>> *Reply-To: *Reid Kleckner <rnk at google.com>
>> *Date: *Thursday, April 9, 2020 at 1:20 PM
>> *To: *James Y Knight <jyknight at google.com>
>> *Cc: *"llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
>> *Subject: *Re: [llvm-dev] Upgrading LLVM's minimum required CMake version
>>
>>
>>
>> I would add my voice to Chris's: building out of the box on standard
>> distros is a valuable feature. I don't have time to really participate in
>> this discussion, but I'd discourage us from adding any more steps at all to
>> the LLVM getting started document.
>>
>>
>>
>> When I started working on compilers, it was important that I could build
>> LLVM on the system and hardware that I had. That was a meaningful
>> differentiating advantage over GCC, which sent me off on a side quest to
>> check out two unfamiliar arbitrary precision math libraries, and asked me
>> if I wanted to do a two-stage bootstrap. Forget that. From a modern OS,
>> building LLVM should be as simple as:
>>
>> - Install a standard C++ toolchain
>>
>> - Clone source
>>
>> - Paste a standard configuration command
>>
>> - make
>>
>>
>>
>> If we get too far away from that, we've lost something.
>>
>>
>>
>> On Wed, Apr 8, 2020 at 2:49 PM James Y Knight via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> I am strongly in favor of increasing the minimum CMake version.
>>
>>
>>
>> I think we should NOT be waiting for the next LLVM release to do so, but
>> should do so as soon as practical (e.g. maybe a month from now). A warning
>> message emitted in CMake spam is not likely to help users very much, IMO.
>> An entry in the release notes saying "This version of LLVM now requires
>> CMake X.Y.Z." along with a link to the completely-trivial instructions on
>> how to get, build, and use a new version for building LLVM (WITHOUT having
>> to install it!), should both suffice -- and is more likely to be useful.
>>
>>
>>
>> I do NOT think we should have a policy tying ourselves to versions
>> supported by certain LTS releases. Users of such LTSes can download a newer
>> cmake. We should, of course, strive to not be unnecessarily annoying --
>> even though the amount of work to download a new version is small, it's not
>> zero. We should _consider_ the versions that developers are likely to have
>> pre-installed on their machines, and drop support for those versions only
>> when the new features are judged compelling enough to offset the cost
>> (small-pain-per-developer times number-of-deveopers-affected).
>>
>>
>>
>> I agree with others who say we should only upgrade when would be truly
>> valuable -- not automatically just because a new version exists. We should
>> avoid changing the minimum-requirement too often.
>>
>>
>>
>> FInally, I think we should put the decision of when such an upgrade is
>> judged valuable into the hands of those who are spending the most time
>> working on the build system. We do not need to redo this discussion every
>> time.
>>
>>
>>
>>
>>
>> On Wed, Apr 8, 2020 at 4:36 PM Chris Tetreault via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> We should decide who we consider the major distros to be. In my mind this
>> is Ubuntu, Debian, Fedora, and CentOS/RHEL. We should also consider Visual
>> Studio releases and whatever OSX and the major BSD’s have. (I honestly have
>> no idea so I’ll refrain from speculating)
>>
>>
>>
>> For all of these, we should try very hard to support the most recent LTS.
>> For the previous LTS, it would be nice if we could support it, but we
>> shouldn’t require it. Old LTSs tend to have really out of date packages,
>> especially in times like now with Ubuntu where we’re really close to the
>> current LTS becoming the old LTS.
>>
>>
>>
>> That said, if CMake version X has a killer feature that we need, we
>> should consider upgrading even if it doesn’t fit this criteria. Similarly,
>> we should not just upgrade because the minimum bound of CMake versions
>> supported by this set of OSs increased. The point is to upgrade only when
>> there’s a compelling reason, and this set of OSs is just a heuristic of
>> “most people probably already have this CMake version.”
>>
>>
>>
>> *From:* Shoaib Meenai <smeenai at fb.com>
>> *Sent:* Wednesday, April 8, 2020 12:58 PM
>> *To:* Chris Tetreault <ctetreau at quicinc.com>; Eric Christopher <
>> echristo at gmail.com>
>> *Cc:* llvm-dev at lists.llvm.org
>> *Subject:* [EXT] Re: [llvm-dev] Upgrading LLVM's minimum required CMake
>> version
>>
>>
>>
>> Yeah, I don’t anticipate Windows posing problems. Also, it’s pretty
>> common in Windows to just install software yourself, and CMake ships
>> prebuilt binaries and an installer, so it’s pretty easy to get set up with
>> it.
>>
>>
>>
>> Chris, I’m gonna reiterate a question of mine from an earlier email,
>> since you may have thoughts on it:
>>
>>
>>
>> * If we want to limit ourselves to CMake versions supported by LTS
>> releases of distros, which distros should we consider, and how far back
>> should we go (i.e. is it just the latest LTS or the last two LTS versions)?
>>
>>
>>
>> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Chris
>> Tetreault via llvm-dev <llvm-dev at lists.llvm.org>
>> *Reply-To: *Chris Tetreault <ctetreau at quicinc.com>
>> *Date: *Wednesday, April 8, 2020 at 12:51 PM
>> *To: *Eric Christopher <echristo at gmail.com>
>> *Cc: *"llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
>> *Subject: *Re: [llvm-dev] Upgrading LLVM's minimum required CMake version
>>
>>
>>
>> Visual studio 2019 ships with CMake 3.15.5, which is pretty darn new IMO.
>> From what I can tell, CMake versions are tied to visual studio releases. So
>> assuming we go with “what do recent LTS distros have” as our metric, I
>> think it’s reasonable to say “what do recent visual studio versions have”.
>> It probably makes sense to confirm with MS though before we assume that
>> this is the case.
>>
>>
>>
>> *From:* Eric Christopher <echristo at gmail.com>
>> *Sent:* Wednesday, April 8, 2020 12:41 PM
>> *To:* Chris Tetreault <ctetreau at quicinc.com>
>> *Cc:* Mehdi AMINI <joker.eph at gmail.com>; Louis Dionne <ldionne at apple.com>;
>> llvm-dev at lists.llvm.org
>> *Subject:* [EXT] Re: [llvm-dev] Upgrading LLVM's minimum required CMake
>> version
>>
>>
>>
>> Hi All,
>>
>>
>>
>> Throwing a couple of comments in:
>>
>>
>>
>> Chris's position here has a lot of good points and we want to make sure
>> we're not raising the barrier too high. I definitely want to be able to
>> push ahead with our versions of tools; being able to update quickly is one
>> of the hallmarks of the llvm project. That said, binary packages that can
>> be updated are a minimal first step IMO. I'd really like to not build
>> anything from source :) It seems like there are binaries available for
>> cmake for all of our current platforms, but the windows use case that he
>> brings is definitely a significant one. Can we perhaps reach out and find
>> out the likelihood of a reasonably soonish update there? Linux distros are
>> probably less of a problem - while we all can't use ppas we should be able
>> to do something, similarly with osx.
>>
>>
>>
>> Thoughts?
>>
>>
>>
>> -eric
>>
>>
>>
>> On Wed, Apr 8, 2020 at 9:53 AM Chris Tetreault via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>
>>
>> A line has to be drawn in the sand somewhere. How many “easy” things are
>> we going to require the user to do? Today it’s build a specific CMake from
>> source. What’s next?
>>
>>
>>
>> Not having to manually track down a bunch of dependencies before building
>> is a feature. Not having to have an internet connection at build time (if
>> we were to script the getting of the custom CMake) is a feature. Being able
>> to just call cmake instead of using some build_llvm.sh that (probably
>> poorly) wraps cmake and downloads the correct version is a feature. Being
>> able to use CMake that is distributed with visual studio so that invoking
>> cmake from the developer powershell just works without fiddling with PATHs
>> is a feature. Not having to install msys so that I can invoke
>> download_cmake.sh is a feature. Not having to have the correct version of
>> python (is it 2 or 3?) be on the path in order to invoke download_cmake.py
>> is a feature. Not having to remember to do --recurse-submodules on the llvm
>> repo if we include it as a git submodule is a feature. The list goes on.
>> Yeah, these are all little things, but a bunch of little things adds up to
>> a huge barrier.
>>
>>
>>
>> People use Linux distos because by and large they just have all the
>> dependencies that they need. I know I personally hate installing some open
>> source thing on my machines when they have some dependency that’s not in
>> the repos. Sure, it may be easy to build CMake from source. But now I have
>> two CMakes: one that is automatically updated when I do sudo apt-get
>> upgrade, and one that is just randomly in some folder that’s probably not
>> on the PATH. I personally would really appreciate it if we made an attempt
>> to reduce this sort of friction.
>>
>>
>>
>> Thanks,
>>
>>    Christopher Tetreault
>>
>>
>>
>>
>>
>> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Mehdi
>> AMINI via llvm-dev
>> *Sent:* Wednesday, April 8, 2020 9:06 AM
>> *To:* Louis Dionne <ldionne at apple.com>
>> *Cc:* llvm-dev at lists.llvm.org
>> *Subject:* [EXT] Re: [llvm-dev] Upgrading LLVM's minimum required CMake
>> version
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 8, 2020 at 9:02 AM Louis Dionne <ldionne at apple.com> wrote:
>>
>>
>>
>>
>>
>> On Apr 7, 2020, at 22:16, Mehdi AMINI via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Apr 7, 2020 at 11:27 AM David Blaikie <dblaikie at gmail.com> wrote:
>>
>> I think it does make a difference how many things we ask new developers
>> to do to get up and running - because we've asked them to do one thing
>> doesn't mean it's low-cost to ask them to do another thing.
>>
>>
>>
>> In this case I see it rather that if we ask them to do one quite big
>> thing already, we should be OK with what seems like a trivial one.
>>
>>
>>
>> I strongly agree. I think Mehdi's point can be summarized as (Mehdi, feel
>> free to correct me):
>>
>>
>>
>>     It's incredibly trivial to install CMake, so if a user is *already*
>> required to install a non-default toolchain (which is not so trivial),
>> requiring them to install a non-default CMake is not increasing the barrier
>> by much.
>>
>>
>>
>> Thanks, this is my point indeed!
>>
>>
>>
>> I think it is even slightly stronger than what you wrote since you don't
>> even need to *install* CMake as it can be built and used directly from the
>> build directory: it is entirely non-intrusive on the system.
>>
>>
>>
>> --
>>
>> Mehdi
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=OUvi60kOTuMyRUJcCtHsN-RK1gHy4sXxEGS0pAunCoE&s=W77RObkJ6AlX4-NZ-OApzF80Y5rSjh4gDzuBG4ScjEQ&e=>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RvaD9Q_VY7Y2QSH5JAtJlUDjQZKLr1RSWDceq7JxvZE&s=SdeUoPXT_jrLA6F111g6osrDG6MW34YbjgUwfq1YSl0&e=>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RvaD9Q_VY7Y2QSH5JAtJlUDjQZKLr1RSWDceq7JxvZE&s=SdeUoPXT_jrLA6F111g6osrDG6MW34YbjgUwfq1YSl0&e=>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://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/20200409/4a32e981/attachment-0001.html>