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

On Tue, Mar 10, 2015 at 8:47 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
> > 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).
>
> Well, there is a clear proposal for what it would be used.

I came back into this thread after 10 days of silence to reply to an email
that asked a general question without a specific proposal. I've said I'd
be
interested in seeing the specific proposal in almost every email. I don't
want to just assume Chris or anyone else is going to immediately use some
of the many features that were mentioned previously, I'd like to see
something more concrete in terms of "i want to do X now, it needs Y".

> It seems
> counter productive to ask Chris to implement a patch using 3.0
> features first and then get it rejected because we decided that we
> don't want to move to 3.0 after all.

I'm happy for it to be prior to a patch. I've given an example mulitple
times of how this would make more sense to me to evaluate.

I'm sorry you think I'm treating Linux specially. I've tried not to,
and
explained why, but it didn't seem to make any difference.

I don't know why we're spending this much time debating whether or not
we're debating something. This entire thread seems a bit silly at this
point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150310/b2e65ca2/attachment.html>

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 started replying again in response to a specific question from Chris:

"""
Chandler, do you have any thoughts based on the context in this thread?
"""

Perhaps wrongly, I interpreted this "context" to refer to the recent
trouble encountered by Tobi and others with newer versions of CMake.


I laid out the basis for when I *would* push to raise our minimum cmake
version: when someone would actually like to use a specific feature to make
the build better and can compare the cost of not having that feature with
the (rather small, I agree! just non-zero) cost of requiring getting a
fresh copy of CMake. My belief was and is that this would be an effective
way to help assuage the concerns of those worried about being too
aggressive here.

Maybe Chris is ready to use some features and we can do that right now. The
start of the thread gives one impression, his recent email gave me the
impression otherwise, but he can speak for himself I'm sure. ;]

Maybe Zach is ready to use some features. I'll let him make the case if so.

Maybe everyone is 100% ready to jump to a new version. Cool, I'm all for
that. But when Chris asked me the question, it seemed like the community
had some resistance to newer versions and so I was trying to suggest how to
balance those concerns in a productive  If the community is just in violent
agreement that we should use the latest and greatest, I don't know why
we're still here debating it though.

On Tue, Mar 10, 2015 at 8:51 PM, Chandler Carruth <chandlerc at
google.com>
wrote:
>
> On Tue, Mar 10, 2015 at 8:47 PM, Rafael Espíndola <
> rafael.espindola at gmail.com> wrote:
>
>> > 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).
>>
>> Well, there is a clear proposal for what it would be used.
>
>
> I came back into this thread after 10 days of silence to reply to an email
> that asked a general question without a specific proposal. I've said
I'd be
> interested in seeing the specific proposal in almost every email. I
don't
> want to just assume Chris or anyone else is going to immediately use some
> of the many features that were mentioned previously, I'd like to see
> something more concrete in terms of "i want to do X now, it needs
Y".
>
>
>> It seems
>> counter productive to ask Chris to implement a patch using 3.0
>> features first and then get it rejected because we decided that we
>> don't want to move to 3.0 after all.
>
>
> I'm happy for it to be prior to a patch. I've given an example
mulitple
> times of how this would make more sense to me to evaluate.
>
> I'm sorry you think I'm treating Linux specially. I've tried
not to, and
> explained why, but it didn't seem to make any difference.
>
> I don't know why we're spending this much time debating whether or
not
> we're debating something. This entire thread seems a bit silly at this
> point.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150310/b1d46eaa/attachment.html>

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

On Tue, Mar 10, 2015 at 9:16 PM Chandler Carruth <chandlerc at google.com>
wrote:
>
> Maybe Zach is ready to use some features. I'll let him make the case if
so.
>
 I went and looked over the feature list of 3.0, 3.1, and 3.2.  Here's my
thoughts.  It would be nice if someone else with a different perspective
could do the same thing.

*CMake 3.0*
* The $<UPPER_CASE> and $<LOWER_CASE> generator expressions seem
useful for
cleaning up string comparisons.  No real other killer features I could find.

*CMake 3.1*
* A project generator for Visual Studio 2015 was added.  We don't need to
require this yet, but keep this in mind for when it's time to bump the
minimum MSVC version again.
* $<LINK_ONLY> generator expression looks useful for speeding up builds.
Right now target_link_libraries(A B) will create a dependency from A to B,
so it will force A to build after B is finished.  If A and B are both
static libraries and B doesn't generate code, they could build in parallel.
 $<LINK_ONLY> target_link_libraries(A $<LINK_ONLY:B>) appears to
solve this
and allow A and B to be build in parallel.
* A new $<COMPILE_FEATURES> generator expression appears useful for
cleaning up some existing CMake code we have to detect available compile
features.

*CMake 3.2*
* add_custom_command(BYPRODUCTS) looks very useful for specifying outputs
of custom commands.  There are a number of issues in the LLDB build (not
sure about other projects) where we have a custom command which runs a
python script that generates multiple outputs, and I haven't yet found a
solution for how to get CMake to regenerate those items if you go and
delete the byproducts.  This appears to solve that.
* continue() is a welcome new control flow instruction
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150311/4baf55f5/attachment.html>