Eric Christopher via llvm-dev
2020-Apr-08 19:41 UTC
[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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200408/180ebdc9/attachment.html>
Chris Tetreault via llvm-dev
2020-Apr-08 19:51 UTC
[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<mailto: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<mailto: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<mailto:ldionne at apple.com>>
Cc: llvm-dev at lists.llvm.org<mailto: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<mailto:ldionne at apple.com>> wrote:
On Apr 7, 2020, at 22:16, Mehdi AMINI via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
On Tue, Apr 7, 2020 at 11:27 AM David Blaikie <dblaikie at
gmail.com<mailto: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<mailto: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/20200408/50862e74/attachment.html>
Shoaib Meenai via llvm-dev
2020-Apr-08 19:58 UTC
[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<mailto: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<mailto: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<mailto:ldionne at apple.com>>
Cc: llvm-dev at lists.llvm.org<mailto: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<mailto:ldionne at apple.com>> wrote:
On Apr 7, 2020, at 22:16, Mehdi AMINI via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
On Tue, Apr 7, 2020 at 11:27 AM David Blaikie <dblaikie at
gmail.com<mailto: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<mailto: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=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200408/9ee520ee/attachment-0001.html>
Tobias Hieta via llvm-dev
2020-Apr-08 19:58 UTC
[llvm-dev] Upgrading LLVM's minimum required CMake version
One of the MSVC devs recently said they are pushing for getting cmake 3.17.0 in the next point release which is expected in May. https://www.reddit.com/r/cpp/comments/fluibz/_/fl2bpz1 On Wed, Apr 8, 2020, 21:51 Chris Tetreault via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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 > > _______________________________________________ > 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/20200408/6eb1d601/attachment.html>