Install modern CMake on build docker images

[jkoritzinsky]

Install CMake 3.15.3 on CentOS docker images.

Install CMake on Ubuntu via Kitware's official feed to get the most recent official release (currently 3.15.3) instead of the OS bundled release.

Install CMake 3.15.3 on Alpine 3.9 via the "edge" package repository.

This will enable CoreCLR (along with other repos) to upgrade their build scripts to use modern CMake features and (in some CoreCLR's case) clean up our build scripts with new features available in more recent CMake versions.

I've locally verified that the correct CMake version is installed and that it runs on all of the images.

cc: @jashook @janvorli

@MichaelSimons PTAL

[jkoritzinsky]

@jashook @janvorli with Alpine Linux 3.6 out of support, the docker image that we use for building on Alpine Linux is no longer supported/updatable. To upgrade our CMake version, we'll have to either add the ability to build a rootfs for an amd64 distro on an amd64 distro to our scripts (currently not supported), bump our version of Alpine we build on and against to 3.9 (the oldest version of Alpine not EOL by the .NET 5 release date), or build a 3.7 or 3.8 image to use.

[jkoritzinsky]

Specifically, #149 changed the 3.6 images to build from 3.9.

[janvorli]

As far as I remember, building .NET core on 3.7 and 3.8 doesn't work (the build fails). I think that building on 3.9 works again. I believe I have even verified that binaries built on 3.9 work fine on 3.6 some time ago (thanks to the fact that unlike GLIBC, MUSL doesn't use versioning of symbols), but I don't remember it clearly and I cannot find my notes / emails on that.
The reason for building on 3.6 was the same as for building our GLIBC Linux binaries on CentOS 7 - to be able to support as many distros as reasonable possible. But if I am right that the build done on 3.9 really works on 3.6, we should be able to move to building on 3.9.

[janvorli]

LGTM, thank you! I assume you have verified that the cmake works properly in each of the images you were changing e.g. by building coreclr repo with it.

[MichaelSimons]

@jkoritzinsky, respond when you have finished any manual verification and are ready to merge this PR.

cc @mthalman

[jkoritzinsky]

I've manually validated that coreclr builds with each of the images I changed.

[jkoritzinsky]

@tmds Do you know if RedHat would have any problems building CoreCLR if we upgrade our minimum CMake version to 3.14+?

[tmds]

@tmds Do you know if RedHat would have any problems building CoreCLR if we upgrade our minimum CMake version to 3.14+?

Adding @omajid

[omajid]

Do you know if RedHat would have any problems building CoreCLR if we upgrade our minimum CMake version to 3.14+?

We are already hitting the problem with .NET Core 3.0 on RHEL 7 because the underlying CMake version was bumped to 3.x by dotnet/coreclr#24861. RHEL 7 has 2.x only. We can't use EPEL.

EPEL's cmake3 (what CentOS images were using before this PR) are cmake 3.14.6. I am not sure of how difficult of a bump from 3.14.x to 3.15.x might be. I am going to take a look at building cmake 3.15 on RHEL 7 later this week.

[MichaelSimons]

I've manually validated that coreclr builds with each of the images I changed.

@jkoritzinsky - feel free to merge or let me know if you need me to.

[janvorli]

@omajid 3.14.6 from EPEL should be good enough.

[jkoritzinsky]

Yep 3.14.6 should be fine. Only reason I'm installing 3.15.x is so that we're more explicit about what version we have installed and it just happened to be the current release when I drafted this PR.

[omajid]

@janvorli

3.14.6 from EPEL should be good enough.

Just for additional context: I work for Red Hat and I was commenting on building/packaging .NET Core for RHEL (the rh-dotnet* packages on RHEL 7 and dotnet-sdk-x.y on RHEL 8). We can't use EPEL when building packages for RHEL. So while 3.x is fine on RHEL 8, it is causing us grief on RHEL 7.

I dont think the particular version of 3.x matters much; if we have to hack around to get 3.x, then (unless 3.14 and 15 have significant differences) they should be about equal in terms of effort required to get it usable for .NET Core in RHEL 7.

[jkoritzinsky]

I dont think the particular version of 3.x matters much; if we have to hack around to get 3.x, then (unless 3.14 and 15 have significant differences) they should be about equal in terms of effort required to get it usable for .NET Core in RHEL 7.

Based on this comment, I think we can merge this in since it won't require any additional work from RedHat in addition to what they already have to do for .NET Core 3.0.

@MichaelSimons this is ready to merge.