Hi Todd I have done a dirty fix to get the behavior you want https://github.com/pescobar/easybuild-framework/commit/5942c51244e6cdc25094e5e1a5d32ee2afbbaf0d
I have done quick test and seems to work, but you should redo all your modulefiles Pablo 2014-01-30 Garvey, Cormac T <[email protected]> > I also would prefer that dependent modules also get unloaded. > > Thanks, > Cormac. > > > On Thu, Jan 30, 2014 at 10:25 AM, Heywood, Todd <[email protected]> wrote: > >> Hi Pablo, >> >> Yes, something like that. If you Google on this subject, a number of >> sites utilizing modules come up that says that dependent modules get >> unloaded when "module unload" is done. I don't really know modules though, >> so am unclear on the different results from doing "module load" and "module >> unload" on the same file, where the file has conditionals that load >> unloadewd/undefined dependencies, and also unload dependencies that are >> loaded/defined. Would running "module load" twice result in unloading? :-) >> >> Easybuild developers: this would be a reasonable (optional) feature >> request, maybe? >> >> For right now, I think "module purge" is usable. >> >> Todd >> >> From: Pablo Escobar Lopez <[email protected]<mailto: >> [email protected]>> >> Reply-To: "[email protected]<mailto:[email protected]>" < >> [email protected]<mailto:[email protected]>> >> Date: Thursday, January 30, 2014 at 12:01 PM >> To: "[email protected]<mailto:[email protected]>" < >> [email protected]<mailto:[email protected]>> >> Subject: Re: [easybuild] module unload for toolchains? >> >> 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]<mailto:[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] >> ><mailto:[email protected]<mailto:[email protected]>>> >> Reply-To: "[email protected]<mailto:[email protected] >> ><mailto:[email protected]<mailto:[email protected]>>" < >> [email protected]<mailto:[email protected]><mailto: >> [email protected]<mailto:[email protected]>>> >> Date: Thursday, January 30, 2014 at 10:39 AM >> To: "[email protected]<mailto:[email protected]><mailto: >> [email protected]<mailto:[email protected]>>" < >> [email protected]<mailto:[email protected]><mailto: >> [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]<mailto:[email protected]> >> Phone: +41 61 267 15 82 >> http://www.biozentrum.unibas.ch >> > > > > -- > Cormac Garvey > HPC Software Consultant > Scientific Computing > Idaho National Laboratory > Ph: 208-526-6294 > > -- 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
