search

EESSI / software-layer

Software layer of the EESSI project
https://eessi.github.io/docs/software_layer
GNU General Public License v2.0
23 stars 46 forks source link

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

Closed bedroge closed 4 months ago

bedroge commented 4 months ago

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[bot] commented 4 months ago

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

eessi-bot[bot] commented 4 months ago

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

bedroge commented 4 months ago 
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 commented 4 months ago

@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 commented 4 months ago

@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 commented 4 months ago

@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 commented 4 months ago

@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 commented 4 months ago

@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 commented 4 months ago

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).