intel-oneapi-mkl: change logic for gfortran compatibility

[rscohn2]

Use a variant to request gfortran compatibility instead of toolchain.
See discussion in #43673

@RMeli: Can you test your example. I testing: spack install dla-future ^intel-oneapi-mkl

[RMeli]

@rscohn2 thank you for opening this PR. Sorry for the late reply, but I'm out of office until Wednesday. I'll have a look when I'm back.

[RMeli]

@rscohn2 I see that there are still un-resolved conversations with @alalazo. Should I test this PR now or when they are resolved? (I would prefer the latter.)

From our discussion in #43673 I think a variant might indeed be better for users, since the default behavior will stay the same and not break pure C/C++ projects.

However, I don't think there is a way to make C/C++ projects relying in MKLConfig.cmake to work with downstream Fortran projects. Can we add a warning about this when using the +fortran variant?

[rscohn2]

@alalazo: This is a binary package that does not require compilation. MKL put the C & Fortran support in the same library so we have to know whether to provide libmkl_gf or libmkl_intel. Some packages query spack for the libraries and some packages use cmake to know the mkl library names. If intel-oneapi-mkl returns libmkl_gf and another package uses cmake and links with libmkl_intel, there will be undefined behavior. cmake uses libmkl_intel unless a packages enables fortran and configures gfortran. Until recently, we did not support gfortran in the spack package, so it always supported C (gcc/intel/oneapi) and ifx/ifort.

I don't think spack has enough information to decide which library is needed so I would like to have an explicit variant like gfortran so the user can decide and be sure they are getting what they want.

Modeling of the runtime can be improved, but it will take me a bit to get to it

[alalazo]

@RMeli @rscohn2 Feel free to proceed as soon as this looks good to you. When we'll be at modeling runtimes, I'll be sure to revisit this and ping you both.

[rscohn2]

@RMeli: If it looks ok, can you approve?

[RMeli]

Thanks @rscohn2, LGTM.

But as I said before, it would be good to add some sort of user-facing warning when using intel-oneapi-mkl with gcc, pointing to the possibility to enable this variant.

[rscohn2]

But as I said before, I would be good to add some sort of user-facing warning when using intel-oneapi-mkl with gcc, pointing to the possibility to enable this variant.

Thanks for the reminder.

[rscohn2]

Using fortran-rt check from @alalazo, I added a warning if +gfortran is not used.

[RMeli]

Thank you, I'll test it right now.

[RMeli]

I could confirm that with ~gfortran the old behavior appears, and +gfortran fixes my issue.

I did not see any warning/message though.

[rscohn2]

I did not see any warning/message though.

As a test, I made blaspp depend on fortran:

    depends_on("fortran", type="build")    

and then did:

spack install blaspp intel-oneapi-mkl ~gfortran

It does not emit a warning:

        if self.spec.satisfies("^[virtuals=fortran-rt] gcc-runtime"):                                                                      
                tty.warn("Use intel-oneapi-mkl +gfortran for GNU Fortran support")     

If I emit the warning for self.spec.satisfies("%gcc") then it will be emitting the warning when fortran is not involved and it will confuse people. I don't see a good way to warn.

[RMeli]

I don't see a good way to warn.

Thanks for double checking. Let's just remove the warning then?

[rscohn2]

I removed the warning, can you approve 1 more time?

[RMeli]

Thank you!

[RMeli]

Sorry, I disabled auto-merge by mistake. I already re-enabled it.