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

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>

> 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).
Well, there is a clear proposal for what it would be used. 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.

It is OK to decide to move once the patch is ready, but I don't see
the point of delaying the decision.

As to way it looks to me linux is being given special treatment:

In the compiler case, we selected minimum versions of different
compilers that are easy to get on each system. In the cmake (and
python) case, things are simpler, there is more or less the same
difficulty in installing a recent version on OS X, Linux and Windows.

Linux is special in that unlike OS X or windows it is even easier to
install old version of cmake (and python), but why do have to support
that extra simplicity? If cmake gets bundled with some future OS X or
Windows toolkit, would that make the situation worse for us?

Cheers,
Rafael

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>