Eating Our Own Ice Cream: Use Conan's CMake recipe

[Croydon]

Changelog: Feature: Use a Conan build of CMake for our build images

https://en.wikipedia.org/wiki/Eating_your_own_dog_food#Alternative_terms

Let's try this first with CMake and get some experience. Later we can

• move more dependencies like this.
• Particular the compilers itself once GCC and LLVM recipes are ready for that. This would makes us vastly more independent of specific Ubuntu versions.
• @madebr is working on a Python recipe, maybe this will work well too ✌️

---

• Requires CMake: Fix minimum GCC version to 4.8 conan-center-index#4147

---

Some explanations:

• GCC 4.6 is too old to build CMake. Hence we download the official binaries von Kitware. This works because this image is 64 bit and there is no GCC 4.6 32 bit container. Kitware does not provide 32 bit binaries. (And these old containers should probably be removed anyways, Are Clang 3.8, GCC 4.6 and and GCC 4.8 images still used? #240)
• Our CMake recipe is building CMake with CMake
• Bootstraping of CMake works via make
• For most other compiler versions, except the newest, we do have 32 bit containers. Here, we can not use the official binaries, but rather we compile the source code and bootstrap a CMake build via make.
• Under regular circumstances, we already have Conan packages for CMake available which can be just downloaded. However, who knows what could happen, so these containers should be able to bootstrap. Only when the Conan remote offers no CMake packages to download, we build the Conan CMake recipe with the CMake binary we acquired previously
• The final image only contains a CMake which was build via Conan (except the GCC 4.6 image)
• In the future, we might want to add a bootstrap option directly to the CMake Conan recipe, but for now, this is fine
• This also works good as a proof-of-concept and this workflow can be used eventually for the compilers, the Python runtime and probably other packages too. But let's see how this performs in practice with CMake as this is ready-to-go right now and much less complex than those other packages

[Croydon]

Ready!

[Croydon]

May I get some feedback here? @uilianries @danimtb @czoido 😃

[uilianries]

LGTM I like this idea

[jgsogo]

Hi! I'm a bit concerned about these changes to these images.

I totally agree we should eat our own dog food and, if these docker images were distributed ONLY to outside parties, I'd totally support installing these tools using Conan. It totally makes sense: Conan generates docker images and uses Conan to install tools 💯

BUT, these images are used in conan-center-index too, these images are the ones we use to compile and generate packages, this CMake is the one we use to compile the packages (cmake/3.18.5 too). If we break cmake package and update the docker image, we can't recover, we won't be able to compile CMake in conan-center-index because the installed CMake is broken.

This is very unlikely, but there is a risk (and some headache) we can avoid. We can talk about this, but we need to be sure about what we are doing and why, it requires some consensus. Maybe we need to differentiate between the images we use in C3i (use an independent mechanism to install tools) and other ones we could start to distribute as "Conan images ready to build your binaries".

[uilianries]

I like how @jgsogo predict possible failures involving CCI and CDT, indeed the risk is real.

What about installing a specific package revision? So we could prevent any possible broken package.

[uilianries]

@Croydon Sorry for creating a conflict with your PR 😞

[Croydon]

I think splitting containers would be the worst possible thing we could do, so personally, I'm against that.

You have a good point to worry about a dead lock situation.

Some ideas:

1. we leave it as it is, if
   * a new recipe revision breaks, we can update the containers by specifying a specific revision
   * the entire Conan remote breaks, we could still check out the recipe from git and leave the rest unchanged
2. we specify right now a specific recipe revision, however, that would mean constant updating work and might be super annoying and confusing. To minimize this, we might want to only update the revision when updating the CMake version itself
3. we check out the recipe right now from git, but this might be an unnecessary complication for an unlikely dead lock situation, in which case we could still do this

I think that 2) might be actually the best idea 🤔

[Croydon]

I pinned the CMake recipe revision

[Croydon]

As another note, it is pretty unlikely that we deploy new Docker images with a broken CMake since the CI here is building Conan packages with CMake in the tests

[Croydon]

Closing this as it would require a complete rewrite by now.

However, some of the concepts are merged by now, like using different container layers, so that temporary files don't get into the final container, using more parameters to configure things and starting to use Conan packages for creating the containers itself (#370) 👏

[uilianries]

@Croydon Thank you for sharing this idea. Indeed we started to think about using Conan packages instead of APT packages on "modern" Docker images. Binutils is a good start because we didn't find the latest version available from an external PPA and building from source would consume even more time when creating a Docker image. As next step, probably we will internalize other tools which are available in Conan Center, or convert them to Conan packages, e.g. git.