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

On 10 March 2015 at 21:08, Chandler Carruth <chandlerc at google.com>
wrote:
>
> On Tue, Mar 10, 2015 at 5:46 PM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>
>> As for the advantages, this seems to make it easier to drop the
>> autoconf build, which would be a really big win for us.
>
>
> My only problem here is this: it *seems*.
>
> I would like concrete and specific advantages. I think we're just being
way
> too hypothetical and vague.
>
> If there are specific things that we cannot do today and could do by
> requiring a certain version of cmake, that would be a good discussion to
> have. Saying that there might be things and that they might help isn't
going
> to get us anywhere. ;]
>From above in this thread:
--------------------------------------------------
I should also point out that CMAKE_SYSROOT and
CMAKE_<LANG>_COMPILER_TARGET (both CMake 3.0 features) would make
fixing compiler-rt's CMake (Bugs 14109 & 21562) a lot easier. Both of
those bugs are currently blockers to depreciating the autotools build
system.
-------------------------------------------------

But it does look like we have a general issue here: Why is linux
special? If requiring a cmake that does't ship with a given system is
an issue at all, then we couldn't use any version of cmake because of
OS X and Windows.

Cheers,
Rafael

> On Mar 10, 2015, at 8:02 PM, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
> 
> But it does look like we have a general issue here: Why is linux
> special? If requiring a cmake that does't ship with a given system is
> an issue at all, then we couldn't use any version of cmake because of
> OS X and Windows.
+1.  I don’t see why Linux deserves special treatment in this area.  Users of
other platforms are required to obtain CMake via external means, either in
binary or source form.

—Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150310/9838c617/attachment.html>

On Tue, Mar 10, 2015 at 8:18 PM, Owen Anderson <resistor at mac.com>
wrote:
> On Mar 10, 2015, at 8:02 PM, Rafael Espíndola <rafael.espindola at
gmail.com>
> wrote:
>
> But it does look like we have a general issue here: Why is linux
> special? If requiring a cmake that does't ship with a given system is
> an issue at all, then we couldn't use any version of cmake because of
> OS X and Windows.
>
>
> +1.  I don’t see why Linux deserves special treatment in this area.  Users
> of other platforms are required to obtain CMake via external means, either
> in binary or source form.
>
I don't know that it is special.

I don't work on OS X at all, and I've not heard complaints from users on
OS
X about the CMake versions or problems with getting or installing LLVM. I
have no idea what the problems are there, but if a particular version of
CMake makes it harder to grab LLVM on OS X and start hacking on it, we
*should* consider than when raising the minimum version.

Same thing for Windows. One interesting aspect though is that Windows
systems don't generally come with *any* version of CMake (or configure, or
autotools or....). So there is no way to make grabbing LLVM and building it
avoid grabbing a version of CMake. We should probably still give some
temporal buffer so folks aren't having to constantly update CMake, etc.

If Linux is special in any regard it is special in that it has a preset
system for managing installed software which does provide CMake and would
be more convenient to use than a manually installed CMake. That said,
clearly any inconvenience here only impacts some of the users, not all of
them.


However, everyone seems to think I'm advocating we never move the CMake
version forward. That isn't what I'm saying at all. What I am saying is
that moving the CMake version forward has a cost. Not a huge insurmountable
cost, but non-zero and I suspect non-trivial cost. As a consequence, I'm
suggesting we do so *once we have a use case* (and I don't mean a
hypothetical use case, but patches or planned patches) and when the merits
of that use case make it worthwhile (I suspect they will be).

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150310/28e965e7/attachment.html>

> On Mar 11, 2015, at 5:45 AM, Renato Golin <renato.golin at
linaro.org> wrote:
> 
> 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.
Note: I continue to have the impression that the discussion is oriented like
there is no other option than building CMake from source.
They ship Linux binaries and there are Ubuntu PPAs available (I know that not
everyone can use PPA, but many can). The burden for LTS user does not really
seem “high”.

Mehdi



> 
> 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 15:20, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> Note: I continue to have the impression that the discussion is oriented
like there is no other option than building CMake from source.
> They ship Linux binaries and there are Ubuntu PPAs available (I know that
not everyone can use PPA, but many can). The burden for LTS user does not really
seem “high”.
That's all good for x86_64. ARM, Mips, PPC and others are not so lucky.

--renato