#710 introduced a change in configure_easybuild to support accelerators but this change has not been incorportated into EESSI-extend. It's not entirely clear how we want to do this either since EESSI-extend supports 4 different scenarios (CVMFS, site, project, user).
Do we want this distinction to apply in all cases? This introduces complexity as the behaviour of the module will depend on whether or not the trigger environment variable (EESSI_ACCELERATOR_TARGET) is set or not, and for the end user there are no protections in place to stop them accidentally installing a CPU build into an accelerator target space. The only "person" automatically setting EESSI_ACCELERATOR_TARGET is the bot, so I think this bit of logic is best suited to the bot build scripts (unless we put protections in place in our EB hooks).
#710 introduced a change in
configure_easybuildto support accelerators but this change has not been incorportated intoEESSI-extend. It's not entirely clear how we want to do this either sinceEESSI-extendsupports 4 different scenarios (CVMFS, site, project, user).Do we want this distinction to apply in all cases? This introduces complexity as the behaviour of the module will depend on whether or not the trigger environment variable (
EESSI_ACCELERATOR_TARGET) is set or not, and for the end user there are no protections in place to stop them accidentally installing a CPU build into an accelerator target space. The only "person" automatically settingEESSI_ACCELERATOR_TARGETis the bot, so I think this bit of logic is best suited to the bot build scripts (unless we put protections in place in our EB hooks).