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

On 03/10/2015 06:38 PM, Mehdi Amini wrote:
> Hi Tobias,
[...]
>>> Also, could we just limit the cmake version on windows builds? In
the
>>> end on linux cmake 2.8.9 works great.
>>
>> Rafael asked if updating the bot is not an option. It indeed is an
option, but requires cmake to be manually downloaded and installed instead of
using the available packages.
>>
>> This is OK for one bot, but it will add complications for everybody who
uses debian and wants to install LLVM. It also will make it more complicated to
move to a fully cmake based build as all such debian based buildbots would
require a manual installation of cmake (I have 12 more of these).
>>
>> Before doing so I wanted to understand if it is indeed intended to
require debian-stable users to *manually* install and manage cmake or if there
is not a lower overhead version. Can this bug not be fixed for windows without
complicating live for debian users?
>
> In light of the list of new features that Chris listed, and considering
that Debian 8 is frozen (RC1 already shipped in January) and should be released
before the next LLVM version (but who knows with Debian…), do you have a plan to
update CMake on all your bots? Or do you still have strong other concerns?
The cmake based systems I am running are updated to 3.0. No need to 
worry about my buildbots.

Chandler previously asked to ensure we stay with a cmake version that is 
available in the Ubuntu packages. If you want to drop this requirement, 
you probably want to cross-check with him.

I personally also believe being a little bit more conservative here 
would be nice, if possible, as it keeps the barrier of entry to LLVM 
lower and also makes moving away from autoconf easier. I suggest that we 
check with Sylvestre if his apt-get builds for ubuntu LTS will keep 
working with cmake 3.0 (after autoconf support has dropped).

Maybe I am over careful here. If I am the only one that conservative, 
feel free to move ahead.

Cheers,
Tobias

(adding chandler to the To line)
> On Mar 10, 2015, at 12:29 PM, Tobias Grosser <tobias at grosser.es>
wrote:
> 
> Chandler previously asked to ensure we stay with a cmake version that is
available in the Ubuntu packages. If you want to drop this requirement, you
probably want to cross-check with him.
Chandler, do you have any thoughts based on the context in this thread? Please
take as long as you need to digest it all, there is no imminent rush here.
> 
> I personally also believe being a little bit more conservative here would
be nice, if possible, as it keeps the barrier of entry to LLVM lower and also
makes moving away from autoconf easier.
Actually, the point I was trying to make earlier is that moving away from
autoconf is HARDER on older versions of CMake. Yes everyone has make and can run
configure, but CMake 2.8.x lacks features that would make it easier to support
the remaining bits of functionality from the autoconf build system that the
CMake one is lacking.

Also, as I’ve pointed out before, building CMake from source is really easy,
even on a system that doesn’t have an existing version of CMake. So while I
understand (and am willing to accept) that installing from packages is easy and
convenient, I’m not sure we should make it a requirement.

Either way, at the moment I have no patches to land which use new features of
CMake, so I’m not actually pushing to raise the minimum version today. As I see
it, this conversation is more about establishing a policy, and determining what
qualifies as a justification to update CMake versions.

Personally I would prefer to say we support all stable CMake releases going back
12 months. That would allow us to take advantage of new features 12 months after
they are introduced, and it keeps us moving forward.

Alternatively if we adopt an approach of raising to the minimum version
supported by Ubuntu LTS and Debian Stable, we’ll be stuck in a cycle where every
two years we get to update to a version we have no influence over.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150310/095623b3/attachment.html>

On Tue, Mar 10, 2015 at 1:06 PM, Chris Bieneman <beanz at apple.com>
wrote:
> (adding chandler to the To line)
>
> On Mar 10, 2015, at 12:29 PM, Tobias Grosser <tobias at grosser.es>
wrote:
>
> Chandler previously asked to ensure we stay with a cmake version that is
> available in the Ubuntu packages. If you want to drop this requirement, you
> probably want to cross-check with him.
>
>
> Chandler, do you have any thoughts based on the context in this thread?
> Please take as long as you need to digest it all, there is no imminent rush
> here.
>
>
> I personally also believe being a little bit more conservative here would
> be nice, if possible, as it keeps the barrier of entry to LLVM lower and
> also makes moving away from autoconf easier.
>
>
> Actually, the point I was trying to make earlier is that moving away from
> autoconf is HARDER on older versions of CMake. Yes everyone has make and
> can run configure, but CMake 2.8.x lacks features that would make it easier
> to support the remaining bits of functionality from the autoconf build
> system that the CMake one is lacking.
>
> Also, as I’ve pointed out before, building CMake from source is really
> easy, even on a system that doesn’t have an existing version of CMake. So
> while I understand (and am willing to accept) that installing from packages
> is easy and convenient, I’m not sure we should make it a requirement.
>
> Either way, at the moment I have no patches to land which use new features
> of CMake, so I’m not actually pushing to raise the minimum version today.
> As I see it, this conversation is more about establishing a policy, and
> determining what qualifies as a justification to update CMake versions.
>
So, I'm very sympathetic to the desire to make the CMake build better.
However, I also am sympathetic to wanting to make it super easy for a new
developer to download build and start using LLVM. I don't think we can make
an effective tradeoff here without specific context.

In the absence of specific features which would make our use of CMake
significantly better, I'm inclined to stick roughly to the version of CMake
in the latest LTS release of ubuntu (I don't know the stable releases of
debian well enough to cite it, but likely the same applies).

But in the presence of *specific* functionality we want to take advantage
of, I think we can and should be reasonable aggressive in leveraging
features to make our builds and tests better.

Ultimately, I think we'll have to make a case-by-case decision. It's
going
to depend on the specific new feature and how much it improves our builds
in order to decide whether its worth dropping support for older cmakes,
even though doing so inconveniences new developers.

Here is how I would try to evaluate any such case: how much will the new
functionality of CMake help a *new developer* using LLVM in the first week
they're playing with it? If the functionality is going to significantly
benefit a new developer as early as the first week which they're using
LLVM, it might well be worth the cost of having to build their own version
of CMake just to build LLVM. I'd would try to evaluate this as a new
developer making that tradeoff.

Anyways, pretty vague until we have a specific case. Hope it helps though.
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150310/e714485b/attachment.html>