Initial archdetect support for RISC-V and custom init script for RISC-V repo

[bedroge]

The added spec file for RISC-V is still empty, and we may want to set $cpu_flag_tag to the right field whenever we want to differentiate between different RISC-V CPUs. But for now this does at least detect the riscv64 architecture, and it will just always fall back to riscv64/generic, which is the only stack that we have anyway.

[eessi-bot]

Instance eessi-bot-mc-aws is configured to build:

• arch x86_64/generic for repo eessi-hpc.org-2023.06-compat
• arch x86_64/generic for repo eessi-hpc.org-2023.06-software
• arch x86_64/generic for repo eessi.io-2023.06-compat
• arch x86_64/generic for repo eessi.io-2023.06-software
• arch x86_64/intel/haswell for repo eessi-hpc.org-2023.06-compat
• arch x86_64/intel/haswell for repo eessi-hpc.org-2023.06-software
• arch x86_64/intel/haswell for repo eessi.io-2023.06-compat
• arch x86_64/intel/haswell for repo eessi.io-2023.06-software
• arch x86_64/intel/skylake_avx512 for repo eessi-hpc.org-2023.06-compat
• arch x86_64/intel/skylake_avx512 for repo eessi-hpc.org-2023.06-software
• arch x86_64/intel/skylake_avx512 for repo eessi.io-2023.06-compat
• arch x86_64/intel/skylake_avx512 for repo eessi.io-2023.06-software
• arch x86_64/amd/zen2 for repo eessi-hpc.org-2023.06-compat
• arch x86_64/amd/zen2 for repo eessi-hpc.org-2023.06-software
• arch x86_64/amd/zen2 for repo eessi.io-2023.06-compat
• arch x86_64/amd/zen2 for repo eessi.io-2023.06-software
• arch x86_64/amd/zen3 for repo eessi-hpc.org-2023.06-compat
• arch x86_64/amd/zen3 for repo eessi-hpc.org-2023.06-software
• arch x86_64/amd/zen3 for repo eessi.io-2023.06-compat
• arch x86_64/amd/zen3 for repo eessi.io-2023.06-software
• arch aarch64/generic for repo eessi-hpc.org-2023.06-compat
• arch aarch64/generic for repo eessi-hpc.org-2023.06-software
• arch aarch64/generic for repo eessi.io-2023.06-compat
• arch aarch64/generic for repo eessi.io-2023.06-software
• arch aarch64/neoverse_n1 for repo eessi-hpc.org-2023.06-compat
• arch aarch64/neoverse_n1 for repo eessi-hpc.org-2023.06-software
• arch aarch64/neoverse_n1 for repo eessi.io-2023.06-compat
• arch aarch64/neoverse_n1 for repo eessi.io-2023.06-software
• arch aarch64/neoverse_v1 for repo eessi-hpc.org-2023.06-compat
• arch aarch64/neoverse_v1 for repo eessi-hpc.org-2023.06-software
• arch aarch64/neoverse_v1 for repo eessi.io-2023.06-compat
• arch aarch64/neoverse_v1 for repo eessi.io-2023.06-software

[eessi-bot]

Instance eessi-bot-mc-azure is configured to build:

• arch x86_64/amd/zen4 for repo eessi-hpc.org-2023.06-compat
• arch x86_64/amd/zen4 for repo eessi-hpc.org-2023.06-software
• arch x86_64/amd/zen4 for repo eessi.io-2023.06-compat
• arch x86_64/amd/zen4 for repo eessi.io-2023.06-software

[bedroge]

user@starfive:~$ source /cvmfs/riscv.eessi.io/versions/20240402/init/bash
Found EESSI repo @ /cvmfs/riscv.eessi.io/versions/20240402!
archdetect says riscv64/generic
Using riscv64/generic as software subdirectory.
Found Lmod configuration file at /cvmfs/riscv.eessi.io/versions/20240402/software/linux/riscv64/generic/.lmod/lmodrc.lua
Found Lmod SitePackage.lua file at /cvmfs/riscv.eessi.io/versions/20240402/software/linux/riscv64/generic/.lmod/SitePackage.lua
Using /cvmfs/riscv.eessi.io/versions/20240402/software/linux/riscv64/generic/modules/all as the directory to be added to MODULEPATH.
Initializing Lmod...
Prepending /cvmfs/riscv.eessi.io/versions/20240402/software/linux/riscv64/generic/modules/all to $MODULEPATH...
Environment set up to use EESSI (20240402), have fun!

[boegel]

@bedroge Do we really need to introduce a separate riscv branch here?

Why can't we take an approach like we're doing for zen4, through a subdirectory in easystacks/* ?

[bedroge]

@bedroge Do we really need to introduce a separate riscv branch here?

Why can't we take an approach like we're doing for zen4, through a subdirectory in easystacks/* ?

Since it's in a different repo, we need different init scripts etc. I don't think we can (easily) reuse all those files from the production repo?

[boegel]

@bedroge Do we really need to introduce a separate riscv branch here?
Why can't we take an approach like we're doing for zen4, through a subdirectory in easystacks/* ?

Since it's in a different repo, we need different init scripts etc. I don't think we can (easily) reuse all those files from the production repo?

Right, ok.. I forgot about that part.

[bedroge]

@bedroge Do we really need to introduce a separate riscv branch here?
Why can't we take an approach like we're doing for zen4, through a subdirectory in easystacks/* ?

Since it's in a different repo, we need different init scripts etc. I don't think we can (easily) reuse all those files from the production repo?

Right, ok.. I forgot about that part.

You can override most of that stuff as a user/builder (EESSI_VERSION_OVERRIDE and EESSI_CVMFS_REPO_OVERRIDE etc), but it's really annoying that you have to do that every time, especially for new users who want to try it out.

Edit: alternatively we could add a check to the production repo init scripts somewhere, and if it detects riscv64, it should just print a warning, automatically override these variables and redirect to the riscv repo?

[boegel]

@bedroge Do we really need to introduce a separate riscv branch here?
Why can't we take an approach like we're doing for zen4, through a subdirectory in easystacks/* ?

Since it's in a different repo, we need different init scripts etc. I don't think we can (easily) reuse all those files from the production repo?

Right, ok.. I forgot about that part.

You can override most of that stuff as a user/builder (EESSI_VERSION_OVERRIDE and EESSI_CVMFS_REPO_OVERRIDE etc), but it's really annoying that you have to do that every time, especially for new users who want to try it out.

Edit: alternatively we could add a check to the production repo init scripts somewhere, and if it detects riscv64, it should just print a warning, automatically override these variables and redirect to the riscv repo?

Maybe short-term, that makes sense, since to some extent riscv.eessi.io is going to be a temporary repo...
As soon as we have sufficient RISC-V support in software.eessi.io, we want people to actually that?

[bedroge]

I'm closing this PR and will open a new one with the aforementioned approach (changing the init scripts of the production repo, and let the redirect to riscv.eessi.io).