Container selection and installation

[MarDiehl]

I struggled a little with the installation scripts when implementing #299 and I'm not very happy with the nested if-statements that I had to implement to support the Intel compiler.

Would it be of interest to look for solutions for a cleaner logic? I don't have a very clear plan, but would look into

• Separation of base installation (compiler) and extra libraries
• Less implicit rules for the installation
• Use containers with pre-installed compilers (https://hub.docker.com/_/gcc, https://hub.docker.com/r/silkeh/clang/tags)

[Flamefire]

I would like to avoid containers if possible as IIRC the raw images from GHA are faster, likely to more up to date apt caches, proxies and no/less virtualization overhead. On the other hand they are less stable as there have been breakages before.

Using custom containers which need to be maintained isn't worth the effort IMO. So just using Ubuntu-xx either base OS or container is IMO better and more transparent for maintainers.

Also I don't see much wrong with the current logic: For the most common cases we automatically select the right default packages to install. The intel compiler is a special case in that it can't be apt-installed

Separation of base installation (compiler) and extra libraries

The current solution is a trade-off: If you have 2 options like: "compiler-install", "other-install" the end-user might need to set more options in some cases and less in others. Having a single "install" option allows to either install only the default package or fully control what to install which is at least simpler to explain. Again only in my opinion.

So I don't see how there could be "Less implicit rules for the installation": For the user there is basically this one only.

What exactly would you consider a "cleaner logic"?

[MarDiehl]

Using custom containers which need to be maintained isn't worth the effort IMO. So just using Ubuntu-xx either base OS or container is IMO better and more transparent for maintainers.

My hope would be that the official gcc containers are good enough. So instead of installing the compilers from the PPA at each run, an already working container can be used without any maintenance. If that works also for clang, the install step would be reduced to the installation of extra packages for specific variants.

What exactly would you consider a "cleaner logic"?

The current logic is something like "if no install specific packages are requested, install gcc if the compiler is gcc or clang, if the compiler is clang also install clang and no nothing if the compiler is from Intel with some additional logic to map between the compiler key (which needs to be the name of the package in the PPA) to the executable".
I think it would have been easier for me to have a step that installs the compiler (which is vendor specific and might be skipped if the use of predefined containers works out nicely) and a step that installs extra dependencies (from matrix.install).

[Flamefire]

I think it would have been easier for me to have a step that installs the compiler (which is vendor specific and might be skipped if the use of predefined containers works out nicely) and a step that installs extra dependencies (from matrix.install).

The current approach was chosen as the most common use case for the install key was to overwrite the choice of the default compiler package to install

We can (and with Intel do) change the default compiler installation to nothing when using a container. The code could be cleaner and better documented though.

If we see use cases of the install key being used to only add additional packages but not changing the compiler we could look into adding a compiler_packages key in addition to install. However for the reusable workflow that was the target of the PR we don't have something like that. Everything in install is either the compiler or a stdlib/compiler-related package.
So I'm not sure if we really gain much there with that.