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

[Renato Golin via llvm-dev]

On 27 April 2016 at 16:29, Chandler Carruth <chandlerc at google.com> wrote:
> 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.

I agree, this is one of the strong points towards the move. Much more
relevant than both personal preferences.


> 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?

I may digress a little, so bear with me. But just to be sure, I want
you to know that I don't disagree with the upgrade, I just want to
make the reasons clear.

Today, installing CMake (or any dep) from packages means they were
validated and released by people that did the validation.

Right now, I *need* CMake 3.x and Ninja 1.5.* (because of LINK_POOL),
and I have no access on my ageing boards to install them from
packages. so I have gone to the trouble to download a *stable* copy of
the sources, and built from source.

This, however, adds to the maintenance of adding new boards, or
putting them back online when they fail. Work done at those times is
stressful, because we're out of coverage until I can put them back in
production. It's not a lot of work, but it's a very stressful one. But
I'm willing to consciously pay the price and I do so with great care.

But asking people to build CMake encourages them to build whatever
stable, or even unstable versions of CMake. Not that they can't do it
today, but being this the recommended way means people will think less
about that step and just get whatever is easier. That's where unknown
bugs in unstable versions will catch us, because no one will know it's
an unstable CMake version on a buildbot until a lot of time has been
wasted.

I agree, however, that this is not a very strong argument. But it's
stronger than personal preference. That's why I was asking for the
real reasons.


> - 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).

Note that this is *current* and mostly x86_64. Life on ARM, MIPS and
probably PPC is not as shiny.

At least on ARM, different boards may have different (old) systems
that they were validated with and will *not* upgrade, at least not
officially. Modulo some serious validation, there's no way I can
upgrade to a current version and expect it to be stable.


> 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.

Right. And I totally want to support Chris and others to make our
build system better.

I am definitely willing to take the hit and upgrade CMake on *all* my
builders (current and future) to a *stable* CMake release if we can
make it clear what we want.

If it's package based, having a minimum version is necessary, since
some new distros don't have the old one. But it's also ok, because
distros validate their packages and control their back-ports, so we
know any update from them is reliable, no matter how new.

If it has to be compiled, than things are a little more complicated.
We need to make sure people understand that *any* production
environment (buildbot/Jenkins, release testing, etc) needs to use a
stable release. We don't control our validation or release test
environments as tight as we should, anyone can add a bot or be a
tester, so having a loose requirement list makes the binaries less
worth, and we do get bug reports on them due to incompatibilities. We
want to decrease that problem, not increase.

I also want to make the releases a community process, where
stakeholders (like Android, Apple, ARM, Sony, etc) can chime in and
validate in their production environments, so that we know all people
that use LLVM have a good, stable and robust base to build upon. Make
it more flaky will counter those goals.

I don't want us to block people from using experimental CMake
versions, but I think we must do so for the CMake scripts that go
upstream. In a nutshell, we should mark a range, not a minimum.
Preferably, a range includes a CMake that exists in Debian Jessie,
since this is going to be the production release of most ARM and
AArch64 machines for the foreseeable future. But stronger arguments
may trump that, I understand.


> 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.

No, having a range and *requiring* stable releases should be more than enough.


> 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.

I absolutely agree, but so far there were no technical arguments to
support any of that.

All version proposals were hand wavy and based on their existence on
this or that OS. I think we need to get a list of the features we
need, match to the *stable* versions available from source, and make
an informed choice. Just like we did with the compilers versions.

cheers,
--renato