Additional compilers

[hiker]

This just adds declarations for additional compilers:

• intel llfcm (icx, ifx)
• nvidia (nvc, nvfortran)
• cray (craycc, crayftn)

And also supports the Cray compiler wrapper: on a Cray system, the compilers are always called cc/ftn - but these are just wrappers that (depending on the loaded modules) will execute either the corresponding gnu, intel, or gnu tool (with additional parameters to automatically link libraries like MPI based on the modules loaded.

Since I didn't want to define Ftn and Cc as compiler wrapper (while ftn is pretty much cray specific, cc is definitely very common and would result in confusion), I have therefore names the compiler wrapper CrayFtn and CrayCc (which will be used to create the compiler wrapper for intel and gnu, e.g. with the names crayftn-ifort, or craycc-gcc).

The actual 'native' compiler are only called using the wrapper script, so in order to have a consistent naming scheme, I used the corresponding names crayftn-ftn and craycc-cc - and the classes are names Crayftn and Craycc. That's a bit confusing (given that CrayFtn etc are wrapper), but it was the best idea I had to use class names and compiler (wrapper) names consistently.

Better ideas are welcome :)

[hiker]

I also removed the whole concept of mixins to handle the compiler version detection. I am aware that I originally suggested it :) But it turns out that in all these cases so far a simple regex is all that is needed, and it additionally simplifies the code (no more need in the mixins to check which compiler type there is to detect the compiler name)

[lukehoffmann]

The code changes themselves look good. I agree with removing the 'mixin' compilers; I was almost going to do that in my last ticket (but I decided to leave it alone because it had gone back and forth enough times 🙂)

I'm confused about the need for each cray compiler to be represented as both a Compiler and a CompilerWrapper. I probably don't understand the use cases for each type.

The docstring for CompilerWrapper says

A decorator-based compiler wrapper. It basically uses a different executable name when compiling, but otherwise behaves like the wrapped compiler.

but in this case we don't have a different executable name. So someone has the option of using the cray wrapper (so they can explicitly use GNU or Intel for the compiler), or they can use the cray compiler object (and then leave the actual compiler choice implicit).

Do you think it would be okay to just remove the Cray Compiler classes, and leave only the CompilerWrapper classes? That seems to be how the mpi wrappers work, and it makes more sense to me.

If we do have both layers for Cray compilers, I don't think it's a good idea to have two class names with only capitalisation to distinguish them (i.e. Craycc and CrayCc). It would be confusing to actually use those classes anywhere else. I'd prefer to give at least one of them a very clear name like CrayCcWrapper or CrayCcCompiler.

[lukehoffmann]

This comment should be "support for gcc/icc"
Or you could say "Intel and GNU"

[hiker]

Indeed.

[hiker]

The code changes themselves look good. I agree with removing the 'mixin' compilers; I was almost going to do that in my last ticket (but I decided to leave it alone because it had gone back and forth enough times 🙂)

Yes, tbh, I expected that just a simple regular expression would not be sufficient, which was why I suggested a more flexible approach.

I'm confused about the need for each cray compiler to be represented as both a Compiler and a CompilerWrapper. I probably don't understand the use cases for each type.

That indeed needs some explanation, my apologies.

On a Cray, the Fortran compiler is always called ftn. But depending on the modules loaded, this will call a different compiler. So if the module PrgEnv-intel loaded, ftn will call ifort (and provide a host of additional parameters, mostly include flags for libraries). If PrgEnv-gnu is loaded, ftn will call gfortran, and with PrgEnv-cray', ftn will invoke the internal name of the real Cray compiler. And in all these cases, the ftn` wrapper will transparently provide the right linker paths depending on the compiler used.

The same with cc - which is on Cray's the same wrapper, and similarly calls icc, gcc, or the intername name of the Cray compiler.

[in theory that sounds very nice - you just change the module loaded, and can test a different compiler ... except that nearly all compiler flags are still specific to the compiler you are using, so you still have to adjust the build environment]

Afaik, you cannot invoke the internal cray compiler directly (it's not in the path, but ifort etc is). Which means, I can't see an easy way of implementing the Cray wrapper for the cray compiler. The best I could do would be to declare cray compiler as (say) Ftn(...), and create a wrapper using CrayFtn(Ftn()) (de-facto both would be using the same compiler executable name, but that should be no problem). But it is still odd, and results in rather strange compiler name (crayftn-ftn, or craycc-cc), which just feels odd

So, I decided to go with the asymmetric solution of not having the Cray compiler as wrapper.

But admittedly, I then ended up with very confusing class names, that is indeed nonsense.

...

Do you think it would be okay to just remove the Cray Compiler classes, and leave only the CompilerWrapper classes? That seems to be how the mpi wrappers work, and it makes more sense to me.

Let me look at this again. As I've said, the issue is that we can't call the real cray compiler, so the wrapper code that verifies version numbering (i.e. that the wrapper and wrapped compiler are indeed the same version) would not work, and we might need to re-implement this - but only for Cray. In case that ftn is supposed to wrap ifort, we need to check that ftn --version and ifort--version is indeed the same.

I'll ponder this a bit, and see if I can come up with better names or a better implementation.

[hiker]

I'll ponder this a bit, and see if I can come up with better names or a better implementation.

I have renamed the Cray wrapper classes to be CrayCcWrapper, and CrayFtnWrapper (leaving Craycc and Crayftn as the name for the native compilers).

[lukehoffmann]

But it is still odd, and results in rather strange compiler name (crayftn-ftn, or craycc-cc), which just feels odd

Just noting that these are in fact the names that are now hard-coded into the Crayftn and Craycc classes. I don't think they look odd though, based on the logic that these compilers are similar to wrappers, so they are comparable to the crayftn-ifort etc that you will get from the CompilerWrappers

[lukehoffmann]

Thanks, I think that's clearer. I only noticed a couple of comments that should be more accurate

[lukehoffmann]

Sorry I missed this before, but the comment is inconsistent with the code. The name is actually craycc-cc, not craycc-cray

[hiker]

Good catch. Fixed.

[lukehoffmann]

Similar here, it's actually crayftn-ftn

[hiker]

And fixed as well.