Arbitrary mixed compiler

[deOliveira-R]

Is there a way to add an arbitrary compiler to compilers.yaml?

The case is that I'm on Mac OS High Sierra and to install openmpi I need gfortran from gcc. This forces me to have a mixed toolchain.

However, a mixed toolchain is not exactly recommended. If possible, I'd like to keep the pure clang compiler available (since it works for many packages) and define an arbitrary mixed toolchain as a workaround only for installing C and Fortran dependent packages, such as openmpi.

I have the system Clang, spack's Clang and spack's GCC installed. I'd like to add an additional compiler to compilers.yaml that has Clang for C/C++ compiler and gfortran, such as:

compilers:
- compiler:
    environment: {}
    extra_rpaths: []
    flags: {}
    modules: []
    operating_system: highsierra
    paths:
      cc: /Library/Developer/CommandLineTools/usr/bin/clang
      cxx: /Library/Developer/CommandLineTools/usr/bin/clang++
      f77: null
      fc: null
    spec: clang@9.0.0-apple
    target: x86_64
- compiler:
    environment: {}
    extra_rpaths: []
    flags: {}
    modules: []
    operating_system: highsierra
    paths:
      cc: /Users/rodrigo/opt/spack-tools/opt/spack/darwin-highsierra-x86_64/clang-9.0.0-apple/gcc-7.2.0-s6yrqijmnetn5kogvcdubvnwqmxt6bzx/bin/gcc
      cxx: /Users/rodrigo/opt/spack-tools/opt/spack/darwin-highsierra-x86_64/clang-9.0.0-apple/gcc-7.2.0-s6yrqijmnetn5kogvcdubvnwqmxt6bzx/bin/g++
      f77: /Users/rodrigo/opt/spack-tools/opt/spack/darwin-highsierra-x86_64/clang-9.0.0-apple/gcc-7.2.0-s6yrqijmnetn5kogvcdubvnwqmxt6bzx/bin/gfortran
      fc: /Users/rodrigo/opt/spack-tools/opt/spack/darwin-highsierra-x86_64/clang-9.0.0-apple/gcc-7.2.0-s6yrqijmnetn5kogvcdubvnwqmxt6bzx/bin/gfortran
    spec: gcc@7.2.0
    target: x86_64
- compiler:
    environment: {}
    extra_rpaths: []
    flags: {}
    modules: []
    operating_system: highsierra
    paths:
      cc: /Users/rodrigo/opt/spack-tools/opt/spack/darwin-highsierra-x86_64/clang-9.0.0-apple/llvm-4.0.1-6dr5en3gbmjerwkpvgjwelj3lawr7udu/bin/clang
      cxx: /Users/rodrigo/opt/spack-tools/opt/spack/darwin-highsierra-x86_64/clang-9.0.0-apple/llvm-4.0.1-6dr5en3gbmjerwkpvgjwelj3lawr7udu/bin/clang++
      f77: null
      fc: null
    spec: clang@4.0.1
    target: x86_64
- compiler:
    environment: {}
    extra_rpaths: []
    flags: {}
    modules: []
    operating_system: highsierra
    paths:
      cc: /Users/rodrigo/opt/spack-tools/opt/spack/darwin-highsierra-x86_64/clang-9.0.0-apple/llvm-4.0.1-6dr5en3gbmjerwkpvgjwelj3lawr7udu/bin/clang
      cxx: /Users/rodrigo/opt/spack-tools/opt/spack/darwin-highsierra-x86_64/clang-9.0.0-apple/llvm-4.0.1-6dr5en3gbmjerwkpvgjwelj3lawr7udu/bin/clang++
      f77: /Users/rodrigo/opt/spack-tools/opt/spack/darwin-highsierra-x86_64/clang-9.0.0-apple/gcc-7.2.0-s6yrqijmnetn5kogvcdubvnwqmxt6bzx/bin/gfortran
      fc: /Users/rodrigo/opt/spack-tools/opt/spack/darwin-highsierra-x86_64/clang-9.0.0-apple/gcc-7.2.0-s6yrqijmnetn5kogvcdubvnwqmxt6bzx/bin/gfortran
    spec: mix@4.0.1.7.2.0
    target: x86_64

However, when I add the "mix" compiler, upon a spack compilers I get:

==> Available compilers
==> Error: 

Is it possible to specify a compiler in this or a similar manner?

[davydden]

U know that there’s documentation, right? ;-)
http://spack.readthedocs.io/en/latest/getting_started.html#mixed-toolchains
Just put path to gfortran instead of null in Clang. Do not invent “mix” compiler, that won’t work.

Reopen if issue persist

[deOliveira-R]

I’m very familiar with the useful documentation of spack, @davydden. Including that page, for which I know I can add gfortan to Clang and make a mixed toolchain. My issue is about having an option of using Clang in a mixed toolchain or not.

The documentation itself says “Modern compilers typically come with related compilers for C, C++ and Fortran bundled together. When possible, results are best if the same compiler is used for all languages.”, which is part of my reason to raise it.

If I can create 2 compilers, one with only Clang for c/c++ and another “virtual” compiler that has the mixed toolchain, all packages that don’t depend on openmpi or a similar dependency could be used in a non-mixed toolchain with only Clang. Only the packages needing mpi would need the mixed toolchain.

This same method would apply to Nag compilers, where one might want to have an option of Nag and an option of Nag+something else (which is not ideal, but sometimes you have no real choice).

[davydden]

Three points:

1. whether or not you substitute null in the default Clang toolchain, won't change it behaviour for packages which only need c/c++. So creating two compilers -- one with null for Fortran part and one with something reasonable -- is not really useful, IMO.

2. even a stronger argument is that Spack currently does not natively support mixed toolchains. You see in packages various switches based on a single compiler family (i.e. patch boost if used with patch('boost_1.63.0_pgi.patch', when='@1.63.0%pgi') compilers, etc). So when you create your mix compiler, all those switches are no longer relevant and IMO you actually will have (on average) more problems with this setup as compared to just pretending that gfortran comes with Clang family.

3. In some packages we actually have hacks which assume that gfortran is is clang family, just to make it work:

if '+fortran' in spec:
            if spec.satisfies('%gcc') or spec.satisfies('%clang'):

p.s. the proper solution is actually separating c/c++ and fortran compilers, we discussed it long time ago (I don't remember the issue name/number), but no-one yet implemented this. The reason being it's not trivial. All places which take compilers (like commandline %intel) and alike now need to be extend to a list of compilers

[davydden]

there are some useful links and discussions #638 (comment) and #568 (comment)

[deOliveira-R]

Thanks for your comments @davydden. I'm thinking about it and there are some arguments I'd like to make as well to know the developer's opinion on it.

whether or not you substitute null in the default Clang toolchain, won't change it behaviour for packages which only need c/c++. So creating two compilers -- one with null for Fortran part and one with something reasonable -- is not really useful, IMO.

I understand your point, however if the pure toolchain and the mixed one are treated as separate it becomes easy to identify what packages were build in a non-ideal environment. This also makes it easy to later recompile the non-ideal packages in a good environment or eliminate them in one swoop.

even a stronger argument is that Spack currently does not natively support mixed toolchains. You see in packages various switches based on a single compiler family (i.e. patch boost if used with patch('boost_1.63.0_pgi.patch', when='@1.63.0%pgi') compilers, etc). So when you create your mix compiler, all those switches are no longer relevant and IMO you actually will have (on average) more problems with this setup as compared to just pretending that gfortran comes with Clang family.

I think this is an absolutely legitimate issue. But this would have to be addressed in any case for a mixed toolchain based on the discussions you sent me. As mentioned in one of the discussions, if I have Clang as C/C++ compiler and gfortran and compile a package that could have patches either for Clang or GCC, one of the patches would be missed. So it seems inevitable that the support for mixed toolchains will become a bit more elaborate.

I understand the idea to separate the compilers, but maybe there are different ways of tackling the issue. It would be possible to make use of the fact that mixed toolchains depend on a mix of pure toolchains by definition. For example, if compilers.yaml had a way to flag a compiler as "mixed" or "virtual" and reference the C/C++ compiler to one of the pure toolchains already defined and the same for the fortran compiler. A tentative conceptual idea could be:

compilers:
- compiler:
    environment: {}
    extra_rpaths: []
    flags: {}
    modules: []
    operating_system: highsierra
    paths:
      cc: <path to gcc>/bin/gcc
      cxx: <path to gcc>/bin/g++
      f77: <path to gcc>/bin/gfortran
      fc: <path to gcc>/bin/gfortran
    spec: gcc@7.2.0
    target: x86_64
- compiler:
    environment: {}
    extra_rpaths: []
    flags: {}
    modules: []
    operating_system: highsierra
    paths:
      cc: <path to llvm>/bin/clang
      cxx: <path to llvm>/bin/clang++
      f77: null
      fc: null
    spec: clang@4.0.1
    target: x86_64
-compiler:
    <whatever flags are necessary>
    mixed:
      CCXX: clang@4.0.1
      Fortran: gcc@7.2.0
    spec: clang-gcc@4.0.1_7.2.0   (or something like that...)

Conceptually this would take advantage of the fact that a mixed toolchain is effectively a virtual toolchain resulting from a mix of pure ones. Therefore, it should be possible to check if it is a mixed one by a mixed entry and, if it is, expand the pure compilers. This could allow using the original compilers to check for patches using the syntax already in place and also to make modules with the same system.

Hopefully you think this idea has its merits.

[davydden]

Hopefully you think this idea has its merits.

it certainly does.

Ping others who might be interested in the discussion @alalazo @adamjstewart @tgamblin

[davydden]

this is also a relevant discussion #896

[davydden]

it's also related to this PR #5503 where clang is being extended to mix with either flang or gfortran. This would of course be more straight-forward if we would have a native way to define mixed compilers.

[deOliveira-R]

Ping @alalazo @adamjstewart @tgamblin