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

[Chris Bieneman via llvm-dev]

Most of the comments I have are actually very well captured by Chandler's email, so I'm not going to pile on. I do have a few things to add.

Renato, in your most recent email you comment about differentiating *stable* vs random versions of CMake built from source. I believe as a community our recommendation should be that people download CMake sources from https://CMake.org/download/ instead of git. Then they get the source of a known stable release. If people choose to pull random git hashes or tags, that is their decision, but since the minimum version I'm proposing is widely available I think it will be uncommon.

So let's talk about ExternalProject.

Is it the only way? No. There are actually several approaches that could be taken here, but let me explain why I want to do it this way.

At a very basic level there are really two high-level approaches to solve the problem of building runtime libraries multiple times:

(1) Do the "Darwin" thing hand hack building multiple targets from the same CMake configuration.
(2) Configure the runtimes multiple times, once per target.

I've been working to try and un-do the horrible Darwin approach we have because I think it has some serious problems, but an alternative solution would be to extend the Darwin approach to every other platform. If you do this you don't need ExternalProject, but you do need to do some really dirty hacks. If you want to understand those hacks, just look at CompilerRTDarwinUtils.cmake in compiler-rt. That is a bit of evil that I’m responsible for, and I’ll be paying down that debt for a long time to come.

Apart from this we also have another problem. The build system makes configuration decisions based on the compiler *at configuration time*. The problem is you really want to configure compiler-rt (and the other runtimes) *after* you've already built clang so the runtimes are configured and built with the clang you just built. The only way to do that is with some mechanism similar to ExternalProject.

We could roll our own. At this point I'm going to put on my "non-constructive reality" hat. I'm not going to do that. I don't mean that from a philosophical stance; I love reinventing me some wheels. I mean that from a "there is no way my boss is going to let me waste that much of my time solving an already solved problem" stance. Even using ExternalProject, this work is largely a side-project of mine, so it is going to take me a while to untangle it.

Replicating ExternalProject would be a lot of work, and it would be a huge maintenance burden to the community. As a data point, the one place in LLVM where we don't use ExternalProject (and we should be) is the cross-compiling goop, and it is a gigantic mess (see: CrossCompile.cmake and every mention of LLVM_NATIVE_BUILD in TableGen.cmake). It is filled with bugs and in desperate need of disentangling. This is another one of my sins that I need to repent.

I feel I should also point out that ExternalProject isn't a silver bullet. It isn't going to solve all our problems, and since it is one of the more actively changing parts of CMake we may find ourselves re-visiting this conversation in a year or two talking about a newer version of CMake.

-Chris


> On Apr 27, 2016, at 9:13 AM, Renato Golin <renato.golin at linaro.org> wrote:
> 
> 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