llvm dev - Mar 2015 - [LLVMdev] [RFC] Raise minimum required CMake version to 3.0

On 11 March 2015 at 04:14, Chandler Carruth <chandlerc at google.com>
wrote:
> Just to rebase things a bit, here is some context.
>
> - This is a 60+ email thread spreading across a month of time.
> - I've not read every single email and I don't think it makes sense
to
> assume the context of the first email applies to the most recent.
I think we all agree that we've all earned the "Bike Shed Master
Badge" today.

Let me re-list all the reasons why we should move on, then all the
problems of doing so, so we can base our arguments on current facts.

== Pro move =
1. Using OBJECT libraries (2.8.8) has massive improvement when linking
on Windows
2. CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_TARGET (3.0) would help fix
compiler-rt builds
3. Ninja "pool = console" would fix the timeout issues on slow builds,
but it's not clear how CMake would do that by default
4. Windows and OSX users already build by hand anyway

Item (1) was already solved by the move to 2.8.12, item (2) is pending
an upgrade to 3.0 and item (3) is uncertain that any move will fix
that.

Item (4) is circumstantial, at best.

== Problems =
A. LTS Linux users (by far, the biggest constituency among Linux
users) are stuck old versions of CMake in their packages.
B. Installing by hand on Linux is, of course, possible, but it
increases the cost of package management (see below). (ref item 4).
C. The number of types of machines Linux runs on eclipses anything
Windows and Mac added together. The number of people affected by this
move would be very big.

In a nutshell, building by hand on Linux is easy, but upsets the
management balance, which multiplied by the number of people and the
number of machines each one of them manages, amounts to an appreciable
cost.

As a concrete example, between ARM and AArch64, we have currently 12
buildbots, and a larger number of internal bots, test boxes,
development boards. Every update would have us to upgrade the
packages, possibly re-build cmake, and re-install it, and work around
library names that are not exactly right (like libX.so.12 instead of
libX.so.11), etc. Doing that on buildbots is never a wise choice.

Windows and Mac users will never have these problems when installing
CMake from source/tarball.

== Discussion =
I just built CMake 3.0 from scratch on a Chromebook 2 and it took me
less than the time I'm writing this email. A user that is advanced
enough to want to compiler LLVM and Clang will most certainly be able
to build CMake (and Ninja) first. Some won't even need to, since CMake
does provide binary releases for Linux on their website.

The biggest problem seems to be a potential increase in the cost of
package management, which is limited to Ubuntu and RHEL. Debian Jesse
(to be marked stable *very* soon) will come with 3.0, and Fedora, Arch
and others are already on it or newer. But LTS users are a large
number of users.

The refusal is not that strong, I agree, but the concrete benefits,
which right now is just "a nicer way to fix compiler-rt" also
don't
seem strong enough to counter that weak refusal.

== Conclusion =
I think neither of sides have a strong argument. That's made clearer
by the amount of bikeshedding we've done. This also seem to have
turned into a Windows vs. Linux battle, which is never a good thing.

We have made intentional to follow LTS releases on our versioning, and
this change would break the model. Breaking the model is not always
bad, but it requires a strong argument. We don't have one. Even if the
counter-argument is also weak, it holds true to our previous
intentions. We did break the model when we moved to C++11 and that was
a good thing. I don't want to move the build infrastructure too
because of that momentum alone.

I personally don't care that much which version of CMake we use, and
I'm trying to be unbiased here. If there is a stronger argument than
item 2 above, then I'd be in favour of moving. Right now, the
arguments are not strong enough, for me, personally.

cheers,
--renato

> The biggest problem seems to be a potential increase in the cost of
> package management, which is limited to Ubuntu and RHEL. Debian Jesse
> (to be marked stable *very* soon) will come with 3.0, and Fedora, Arch
> and others are already on it or newer. But LTS users are a large
> number of users.
>
> The refusal is not that strong, I agree, but the concrete benefits,
> which right now is just "a nicer way to fix compiler-rt" also
don't
> seem strong enough to counter that weak refusal.
So that we can drop autotools, which currently requires anyone wanting
to change the build to install an old version of autoconf, among other
pains. Having two build systems is a way bigger pain than someone
having to install cmake.

I still don't see why we should *ever* take the package management
into consideration if we are OK at all with asking OS X and Windows
users to manually install something. In my experience the claim that
Linux is a more common for development doesn't hold. I personally use
it on a desktop and OS X on a laptop, but most developers I have seem
have a mix of Windows and OS X.

When the issue was mentioned on the context of OS X, the response was
*very* different:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-May/062372.html.

An useful conclusion to this thread would be something like ""we can
switch to cmake 3.0 if a patch to fix pr14109 and/or pr21562 uses
cmake 3.0 features".

Cheers,
Rafael

On 11 Mar 2015, at 12:45, Renato Golin <renato.golin at linaro.org>
wrote:
> 
> A. LTS Linux users (by far, the biggest constituency among Linux
> users) are stuck old versions of CMake in their packages.
To put this in perspective, until the latest Ubuntu LTS release it had been
impossible to build LLVM without building some dependencies manually on Ubuntu
LTS.  This didn't seem to be a problem for the project then and I don't
really see why it would become one now.  It was slightly annoying (our Jenkins
server had to build a load of stuff from source), but RHEL and Ubuntu LTS
generally seem to be aimed at people who think old software with known security
holes is better than new software with undiscovered bugs, so there's less
reason to expect that they'd want to run the very latest LLVM.

David

On 11 March 2015 at 13:06, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
> So that we can drop autotools, which currently requires anyone wanting
> to change the build to install an old version of autoconf, among other
> pains. Having two build systems is a way bigger pain than someone
> having to install cmake.
Can you explain why we need to upgrade CMake to drop autotools?

> I still don't see why we should *ever* take the package management
> into consideration if we are OK at all with asking OS X and Windows
> users to manually install something.
It's the nature of Linux package management. I explained a bit on my
previous email.

> In my experience the claim that
> Linux is a more common for development doesn't hold. I personally use
> it on a desktop and OS X on a laptop, but most developers I have seem
> have a mix of Windows and OS X.
Let's not make this a Windows vs Linux more than it already is,
please. We have all three usages, and that's all we should care about.

cheers,
--renato

On 11 March 2015 at 13:22, David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:
> To put this in perspective, until the latest Ubuntu LTS release it had been
impossible to build LLVM without building some dependencies manually on Ubuntu
LTS.  This didn't seem to be a problem for the project then and I don't
really see why it would become one now.
You mean the GCC version? I don't run LTS, so I don't know. This is a
good argument that makes the refusal even weaker.

--renato

> 3. Ninja "pool = console" would fix the timeout issues on slow
builds,
> but it's not clear how CMake would do that by default
I'm not sure I understand the second part of that statement. As far as I
know, all we have to do is add USES_TERMINAL to the appropriate targets and this
change was made in r222181. At this point having CMake >= 3.2 and Ninja >=
1.5 should be enough to make this work.
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Renato Golin
> Sent: 11 March 2015 12:45
> To: Chandler Carruth
> Cc: jroelofs; LLVM Dev; Tobias Grosser
> Subject: Re: [LLVMdev] [RFC] Raise minimum required CMake version to 3.0
> 
> On 11 March 2015 at 04:14, Chandler Carruth <chandlerc at google.com>
> wrote:
> > Just to rebase things a bit, here is some context.
> >
> > - This is a 60+ email thread spreading across a month of time.
> > - I've not read every single email and I don't think it makes
sense to
> > assume the context of the first email applies to the most recent.
> 
> I think we all agree that we've all earned the "Bike Shed Master
Badge"
> today.
> 
> Let me re-list all the reasons why we should move on, then all the
> problems of doing so, so we can base our arguments on current facts.
> 
> == Pro move => 
> 1. Using OBJECT libraries (2.8.8) has massive improvement when linking
> on Windows
> 2. CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_TARGET (3.0) would
> help fix
> compiler-rt builds
> 3. Ninja "pool = console" would fix the timeout issues on slow
builds,
> but it's not clear how CMake would do that by default
> 4. Windows and OSX users already build by hand anyway
> 
> Item (1) was already solved by the move to 2.8.12, item (2) is pending
> an upgrade to 3.0 and item (3) is uncertain that any move will fix
> that.
> 
> Item (4) is circumstantial, at best.
> 
> == Problems => 
> A. LTS Linux users (by far, the biggest constituency among Linux
> users) are stuck old versions of CMake in their packages.
> B. Installing by hand on Linux is, of course, possible, but it
> increases the cost of package management (see below). (ref item 4).
> C. The number of types of machines Linux runs on eclipses anything
> Windows and Mac added together. The number of people affected by this
> move would be very big.
> 
> In a nutshell, building by hand on Linux is easy, but upsets the
> management balance, which multiplied by the number of people and the
> number of machines each one of them manages, amounts to an appreciable
> cost.
> 
> As a concrete example, between ARM and AArch64, we have currently 12
> buildbots, and a larger number of internal bots, test boxes,
> development boards. Every update would have us to upgrade the
> packages, possibly re-build cmake, and re-install it, and work around
> library names that are not exactly right (like libX.so.12 instead of
> libX.so.11), etc. Doing that on buildbots is never a wise choice.
> 
> Windows and Mac users will never have these problems when installing
> CMake from source/tarball.
> 
> == Discussion => 
> I just built CMake 3.0 from scratch on a Chromebook 2 and it took me
> less than the time I'm writing this email. A user that is advanced
> enough to want to compiler LLVM and Clang will most certainly be able
> to build CMake (and Ninja) first. Some won't even need to, since CMake
> does provide binary releases for Linux on their website.
> 
> The biggest problem seems to be a potential increase in the cost of
> package management, which is limited to Ubuntu and RHEL. Debian Jesse
> (to be marked stable *very* soon) will come with 3.0, and Fedora, Arch
> and others are already on it or newer. But LTS users are a large
> number of users.
> 
> The refusal is not that strong, I agree, but the concrete benefits,
> which right now is just "a nicer way to fix compiler-rt" also
don't
> seem strong enough to counter that weak refusal.
> 
> == Conclusion => 
> I think neither of sides have a strong argument. That's made clearer
> by the amount of bikeshedding we've done. This also seem to have
> turned into a Windows vs. Linux battle, which is never a good thing.
> 
> We have made intentional to follow LTS releases on our versioning, and
> this change would break the model. Breaking the model is not always
> bad, but it requires a strong argument. We don't have one. Even if the
> counter-argument is also weak, it holds true to our previous
> intentions. We did break the model when we moved to C++11 and that was
> a good thing. I don't want to move the build infrastructure too
> because of that momentum alone.
> 
> I personally don't care that much which version of CMake we use, and
> I'm trying to be unbiased here. If there is a stronger argument than
> item 2 above, then I'd be in favour of moving. Right now, the
> arguments are not strong enough, for me, personally.
> 
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On 11 March 2015 at 14:07, Daniel Sanders <Daniel.Sanders at imgtec.com>
wrote:
>> 3. Ninja "pool = console" would fix the timeout issues on
slow builds,
>> but it's not clear how CMake would do that by default
>
> I'm not sure I understand the second part of that statement. As far as
I know, all we have to do is add USES_TERMINAL to the appropriate targets and
this change was made in r222181. At this point having CMake >= 3.2 and Ninja
>= 1.5 should be enough to make this work.
Ok, but CMake 3.2 is *too* new. I'm ok with supporting this on my
bots, to fix them properly, but that's not something I'd like to
impose on everyone.

Thanks for the explanation.

cheers,
--renato

[this is not in reply to anyone in particular]

I don't understand why we don't ship CMake with LLVM. We seem to think
of CMake as a stable system dependency (in the same way that we think of make
and the shell), and it's not. It is an actively developed project, like LLVM
itself, and, frankly, it is not mature enough to be considered part of the base
system. Furthermore, it is not clear that it ever will be: CMake's goal of
building an abstraction layer over many different build systems, on many
different operating systems, combined with our tendency of being on the leading
edge of these features, is not likely to lead to a situation where we can rely
for long periods of time on the 'stable subset' of the functionality
provided. I think we should stop fighting about this and ship a version of CMake
with LLVM. We already have imported dependencies on gtest, etc., and while I
understand this is different, I think it will likely be worthwhile in the long
run. We can always use a suitable system version, if we find one, instead of
rebuilding a version we ship.

 -Hal

----- Original Message -----
> From: "David Chisnall" <David.Chisnall at cl.cam.ac.uk>
> To: "Renato Golin" <renato.golin at linaro.org>
> Cc: "jroelofs" <jonathan at codesourcery.com>, "Tobias
Grosser" <tobias at grosser.es>, "LLVM Dev" <llvmdev at
cs.uiuc.edu>
> Sent: Wednesday, March 11, 2015 8:22:09 AM
> Subject: Re: [LLVMdev] [RFC] Raise minimum required CMake version to 3.0
> 
> On 11 Mar 2015, at 12:45, Renato Golin <renato.golin at linaro.org>
> wrote:
> > 
> > A. LTS Linux users (by far, the biggest constituency among Linux
> > users) are stuck old versions of CMake in their packages.
> 
> To put this in perspective, until the latest Ubuntu LTS release it
> had been impossible to build LLVM without building some dependencies
> manually on Ubuntu LTS.  This didn't seem to be a problem for the
> project then and I don't really see why it would become one now.  It
> was slightly annoying (our Jenkins server had to build a load of
> stuff from source), but RHEL and Ubuntu LTS generally seem to be
> aimed at people who think old software with known security holes is
> better than new software with undiscovered bugs, so there's less
> reason to expect that they'd want to run the very latest LLVM.
> 
> David
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory