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

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>

On 10 March 2015 at 21:30, Chandler Carruth <chandlerc at google.com>
wrote:
> 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).
2.8.12.2 seems to be the common minimum version.

Another thing to consider is the impact of CMake changes on buildbots.
It may not be possible to migrate all buildbots to newer versions, for
instance, Ubuntu is still stuck with 2.8.12.2 I think, but Debian
Jesse is already on 3.0.2 and Arch Linux on 3.1.3.

The "advanced" features I want from CMake are:
 * use pool = console (available in 3.0) to get rid of our ugly hack
due to short timeouts
 * specify -DCMAKE_NINJA_LINK_POOL=2 so we can build on
multi-core/low-mem environments (or distcc).

I don't think the second is even on the drawing board, though I
remember having suggested it a few years back.

None of them would make the life of a new developer easier, though... :)

cheers,
--renato

> On Mar 10, 2015, at 2:53 PM, Renato Golin <renato.golin at
linaro.org> wrote:
> 
> On 10 March 2015 at 21:30, Chandler Carruth <chandlerc at google.com>
wrote:
>> 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).
> 
> 2.8.12.2 seems to be the common minimum version.
Not if you include Debian stable, which is 2.8.9.
> 
> Another thing to consider is the impact of CMake changes on buildbots.
> It may not be possible to migrate all buildbots to newer versions, for
> instance, Ubuntu is still stuck with 2.8.12.2 I think, but Debian
> Jesse is already on 3.0.2 and Arch Linux on 3.1.3.
> 
> The "advanced" features I want from CMake are:
> * use pool = console (available in 3.0) to get rid of our ugly hack
> due to short timeouts
> * specify -DCMAKE_NINJA_LINK_POOL=2 so we can build on
> multi-core/low-mem environments (or distcc).
> 
> I don't think the second is even on the drawing board, though I
> remember having suggested it a few years back.
> 
> None of them would make the life of a new developer easier, though... :)
Unless we have new developers who enjoy cross compilation.
> 
> cheers,
> --renato

> On Mar 10, 2015, at 2:30 PM, Chandler Carruth <chandlerc at
google.com> wrote:
> 
> 
> On Tue, Mar 10, 2015 at 1:06 PM, Chris Bieneman <beanz at apple.com
<mailto: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
<mailto: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.
At the same time, I suggest taking into account the overhead/difficulty of
installing a dependency (cmake or another) on a platform. For instance in this
case rebuilding from source is not the only option, there is at least this PPA:
https://launchpad.net/~george-edison55/+archive/ubuntu/cmake-3.x that provides
cmake 3.0.2 on trusty.

— 
Mehdi

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

On Tue, Mar 10, 2015 at 3:05 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> At the same time, I suggest taking into account the overhead/difficulty of
> installing a dependency (cmake or another) on a platform. For instance in
> this case rebuilding from source is not the only option, there is at least
> this PPA: https://launchpad.net/~george-edison55/+archive/ubuntu/cmake-3.x
that
> provides cmake 3.0.2 on trusty.
>
I generally agree that we should consider generally how easy it is to get a
package, regardless of whether it is built from source or not. However, for
lots of folks an arbitrary PPA may viable for security reasons.

Anyways, this is all speculative. i'd rather discuss this with a concrete
proposal to bump the version up, what we get in exchange for that, and the
implications it has on folks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150310/a5f61f5b/attachment.html>

On 3/10/15 3:53 PM, Renato Golin wrote:
> On 10 March 2015 at 21:30, Chandler Carruth <chandlerc at google.com>
wrote:
>> 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).
>
> 2.8.12.2 seems to be the common minimum version.
>
> Another thing to consider is the impact of CMake changes on buildbots.
> It may not be possible to migrate all buildbots to newer versions, for
> instance, Ubuntu is still stuck with 2.8.12.2 I think, but Debian
> Jesse is already on 3.0.2 and Arch Linux on 3.1.3.
Renato, what do you mean by "stuck with" here? Do you mean this is the
version that comes pre-installed, or is this the latest version of CMake 
that will build on those platforms? If the latter, that's a significant 
concern.


Jon
>
> The "advanced" features I want from CMake are:
>   * use pool = console (available in 3.0) to get rid of our ugly hack
> due to short timeouts
>   * specify -DCMAKE_NINJA_LINK_POOL=2 so we can build on
> multi-core/low-mem environments (or distcc).
>
> I don't think the second is even on the drawing board, though I
> remember having suggested it a few years back.
>
> None of them would make the life of a new developer easier, though... :)
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded