llvm dev - Apr 2016 - [cfe-dev] Fwd: Raising CMake minimum version to 3.4.3

> To be clear, I'm not against moving the version up, I just want to
> make sure that people understand that this is not *just* a version
> upgrade, but a development philosophy move for all Linux developers
> and production environments (of which we have plenty). This move was
> proposed before and was rejected for the reasons I pointed out:
> maintenance.
Yes. It is a move to put linux developers in the same position as
windows and OS X ones, which is a *very* reasonable thing to do.

Cheers,
Rafael

On 27 April 2016 at 15:39, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
> Yes. It is a move to put linux developers in the same position as
> windows and OS X ones, which is a *very* reasonable thing to do.
Apart from the fact that neither Windows nor OSX users have a choice.

We have discussed this before, Rafael, and I don't think doing it
again will yield different results unless new evidence is brought to
light.

Unless there is a feature in a newer CMake that we *must* have, I see
no need to upgrade the version. In the same way we've been holding on
C++11/14 functionality because MSVC couldn't cope with anything until
recently.

Trying to go too fast on the cool tools can create a patchwork of
versions and functionality that will make it very hard to debug
buildbot problems.

LLVM is not a toy any more, we can't just expect that everyone can get
the same environment we have on our own machines, or we'll fall into
the "works for me" style of closing bugs that is pervasive of open
source projects where only a few people ever commit code to.

Now, back to Chris' point:

Is the ExternalProject the only sane way to build compiler-rt and
libc++? Because this IS a big point.

Will it allow a way to build Compiler-RT and libc++ for *all*
supported platforms (as in -DLLVM_TARGETS_TO_BUILD)? Would it be
possible (even if not nice) to do so with an older version of CMake?
How worse would it be, if possible?

Until we can answer all these questions, build times and personal
preferences have no impact on such a big decision.

cheers,
--renato

On Wed, Apr 27, 2016 at 10:54 AM Renato Golin via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On 27 April 2016 at 15:39, Rafael Espíndola <rafael.espindola at
gmail.com>
> wrote:
> > Yes. It is a move to put linux developers in the same position as
> > windows and OS X ones, which is a *very* reasonable thing to do.
>
> Apart from the fact that neither Windows nor OSX users have a choice.
>
> We have discussed this before, Rafael, and I don't think doing it
> again will yield different results unless new evidence is brought to
> light.
>
> Unless there is a feature in a newer CMake that we *must* have, I see
> no need to upgrade the version. In the same way we've been holding on
> C++11/14 functionality because MSVC couldn't cope with anything until
> recently.
>
I don't think this is really the right tradeoff.

The folks working on our build infrastructure have limited time. Making
them cope with designing the usage of CMake in such a way that it
gracefully degrades across many major versions of CMake makes their work
substantially harder, and even if it is theoretically possible to do, it
may become sufficiently annoying or slow to do that we simply don't get
improvements to how we build things.

And I think that the same tradeoff holds for C++11 features. We didn't
*need* any of them, and we actually pushed the Windows platform harder than
all of the others because it was the one holding us back. And I think that
was good because it made the developers substantially more productive. In
this case, it's just the build infrastructure and not the entire codebase,
but I think a similar argument holds. If the functionality in CMake 3.4
makes Chris's job on CMake substantially easier, and it at least seems
reasonable to get access to that version of CMake, I'm very supportive of
the change.

>
> Trying to go too fast on the cool tools can create a patchwork of
> versions and functionality that will make it very hard to debug
> buildbot problems.
>
I'm not really sure how pushing towards newer released and stable versions
will cause *more* of a patchwork of versions than following the distro
installed versions. It seems to involve strictly fewer versions of CMake.
But maybe I'm not understanding your concern here?

>
> LLVM is not a toy any more, we can't just expect that everyone can get
> the same environment we have on our own machines, or we'll fall into
> the "works for me" style of closing bugs that is pervasive of
open
> source projects where only a few people ever commit code to.
>
I don't see anyone on the thread arguing that. I think Chris is trying to
argue instead that this version of CMake is sufficiently widely available
that we should adopt it because the benefits outweigh the costs.

But I do think we need to carefully evaluate the availability outside of
Debian and Ubuntu distros, so I did some more research and found:

- Most major Linux distros have support out of the box in their
"current"
version (OpenSUSE, Fedora, Ubuntu, Debian, Arch), and several in a released
version (Ubuntu, Debian, Arch).
- FreeBSD has support out of the box in the latest port snapshot (as Chris
indicated)
- Homebrew and fink (package managers for OSX) have support out of the box,
and CMake provides binaries for OSX that can be readily installed
- Windows has binary installers available from CMake

There are some OSes where this version is unavailable even in the latest
release. The most notable IMO is CentOS which doesn't have it in any
release. The next most notable is OpenSUSE which only has it in its latest
"tumbleweed" rolling update. I just don't think it is reasonable
for us to
continue to hold back our development tools based on these limitations. I
think we regressed several more distros when we switched our requirement to
GCC 4.7.

But clearly we *do* need a fallback option for folks that are on an OS that
doesn't provide CMake or that can't install packages using the package
manager into the primary OS. I'm totally supportive of that use case.

Here is the thing: the requirements to build and *use* CMake (not install!)
are a strict subset of the requirements to build and *use* LLVM itself. So
I see no way that this will be a limiting factor for folks. If it would
help we could even bundle a copy of the CMake source code at a known good
snapshot in the LLVM project and write a wrapper script to bootstrap it
into a known location and then use it for subsequent builds ... but that
seems unnecessary to me.


I'll go back to my analogy: we require a relatively modern C++ compiler (in
fact, it is past due to update our requirements there....). The reason is
that if you are building a compiler from source, it seems entirely
reasonable to expect you to either use a relatively modern OS environment,
or to have the wherewithal to bootstrap things using one of the numerous
options available. Adding CMake to the potential set of things you need to
bootstrap seems like an extremely small incremental burden compared to that
of getting a modern C++ toolchain. (Although clearly they won't always both
be required in the same situations.)


> Now, back to Chris' point:
>
> Is the ExternalProject the only sane way to build compiler-rt and
> libc++? Because this IS a big point.
>
> Will it allow a way to build Compiler-RT and libc++ for *all*
> supported platforms (as in -DLLVM_TARGETS_TO_BUILD)? Would it be
> possible (even if not nice) to do so with an older version of CMake?
> How worse would it be, if possible?
>
> Until we can answer all these questions, build times and personal
> preferences have no impact on such a big decision.
>
I think removing impedance from the development of the CMake build, or
enabling new functionality such as properly bootstrapped runtime libraries,
are absolutely things to weigh against the cost of using a newer tool.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160427/79ecfb8b/attachment.html>

> The folks working on our build infrastructure have limited time. Making
them cope with designing the usage of CMake in such a way that it
gracefully degrades across many major versions of CMake makes their work
substantially harder, and even if it is theoretically possible to do, it
may become sufficiently annoying or slow to do that we simply don't get
improvements to how we build things.
>
> And I think that the same tradeoff holds for C++11 features. We didn't
*need* any of them, and we actually pushed the Windows platform harder than
all of the others because it was the one holding us back. And I think that
was good because it made the developers substantially more productive. In
this case, it's just the build infrastructure and not the entire codebase,
but I think a similar argument holds. If the functionality in CMake 3.4
makes Chris's job on CMake substantially easier, and it at least seems
reasonable to get access to that version of CMake, I'm very supportive of
the change.

Thanks. I think this is a perfect summary. In the end of the day it is a
tradeoff of who spends time on what. And upgrading cmake takes very little
time compared to having to support old versions.

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160427/ea93342f/attachment.html>