maybe this is what you are looking for: https://github.com/hpcugent/easybuild-framework/issues/714#issuecomment-26036880
You can modify your modules like this or modify easybuild to automatically generate the modules like this. I think the place to tweak is here https://github.com/hpcugent/easybuild-framework/blob/master/easybuild/tools/module_generator.pybut the EB developers can give you better advice about this. Another option is teaching your users to user "module purge" when they need to switch to a different application... regards, Pablo. 2014/1/30 Heywood, Todd <[email protected]> > Hi Fotis, > > Thanks. That may be fine if you are building your entire installation with > Easybuild. But here we already have an installed base (stable, with a > number of older versions), and I would like to use Easybuild for extra, or > bleeding-edge versioned software. > > So the next thought is how to let users know which modules they will need > to unload (for the dependencies of the module they load). Any ideas? > > Todd > > From: Fotis Georgatos <[email protected]<mailto:[email protected]>> > Reply-To: "[email protected]<mailto:[email protected]>" < > [email protected]<mailto:[email protected]>> > Date: Thursday, January 30, 2014 at 10:39 AM > To: "[email protected]<mailto:[email protected]>" < > [email protected]<mailto:[email protected]>> > Subject: Re: [easybuild] module unload for toolchains? > > > Dear Todd, > > On Jan 30, 2014, at 4:33 PM, Heywood, Todd wrote: > Details: I have built Python3 for the goalf toolchain: > Python/3.2.5-goalf-1.5.12-no-OFED. This uses GCC 4.8.1, while our "default" > GCC is older. If someone with other software build with our 'default" > installations wants to use Python3, they would do "module unload > Python/3.2.5-goalf-1.5.12-no-OFED" after their program finishes. But the > newer GCC 4.8.1 remains in the environment, and their other software may > crash since it was built with and older GCC (libraries). > > At the moment, we consider this more of a feature than a bug: > you take the pain of unloading the modules if you really intend > to try the ABI compatibility between different modules. > > The approach that we all take is, to stick to 2-3 toolchains > and build all the relevant modules for them... > > Then, we encourage users to pick early on their toolchain "space" and, > then potential compatibility issues are greatly reduced. > > best, > Fotis > > -- > echo "sysadmin know better bash than english" | sed s/min/mins/ \ > | sed 's/better bash/bash better/' # Yelling in a CERN forum > > > > > > -- Pablo Escobar López HPC systems engineer Biozentrum, University of Basel Email: [email protected] Phone: +41 61 267 15 82 http://www.biozentrum.unibas.ch
