On 30/08/14 01:11, Trey Dockendorf wrote:
Thanks for feedback. I'm ironing out the final builds in my Lmod (no-EB)
environment while in parallel I'm working to build everything in EB to match
what we have already built manually.
Now comes what may seem like an unnecessary issue, but something I have to
consider if my timeframe requires us to go live without EB and then switch to
EB in the future (my goal is to have EB as method for managing our apps).
The issue is that currently all our apps are built using all lowercase names. So
"gcc/4.8.2" and "openblas/0.2.11". I have found that I can successfully build
in EB gcc using a lowercase module name if my GCC-4.8.3.eb file has the following:
easyblock = 'EB_GCC'
name = 'gcc'
...
However when I go to build a gcc dependent app things break.
I tried naming file ACML-6.0.5.7-GCC-4.8.3-gfortran64.eb and ACML-6.0.5.7-gcc-4.8.3-gfortran64.eb. With each
of those I tried setting the toolchain name to both "GCC" and "gcc". I also tried
various permutations of the "--robot" argument pointing at the directory containing GCC-4.8.3.eb
(also tried using gcc-4.8.3.eb).
If I set ACML's toolchain name to "gcc" I of course get "Toolchain gcc not found,
available toolchains:" etc.
If I set ACML's toolchain name to "GCC" I get "No toolchain element 'GCC' found for
toolchain {'dummy': True, 'toolchain': {'version': 'dummy', 'name': 'dummy'}, 'name': 'GCC',
'versionsuffix': '', 'version': '4.8.3', 'parsed': True}"
Is there a way to have the "GCC" module called "gcc" within EB?
Yes, you can use a custom module naming scheme, which would probably
derive from the existing HierarchicalMNS.
Documentation for that is available at
https://github.com/hpcugent/easybuild/wiki/Using-a-custom-module-naming-scheme,
but (still) needs to be updated w.r.t. the extended support for
hierarchical schemes.
Second question regarding migration of existing Lmod environment into EB, how does EB
handle modulefiles that are not a part of software? For example I have two right now
under Core and the "StdEnv" module is loaded at login:
It doesn't care about non-software modules that are loaded when EB is
being used. We always have a "cluster" module loaded, and that works.
EasyBuild takes into account that certain modules may have been loaded,
and should stay loaded.
I haven't used this in combination with sticky modules myself (maybe
others have).
If you notice any issues related to this, let us know, since that would
be a bug.
StdEnv.lua:
load("brazos")
-- Requires --force to remove this module
add_property("lmod", "sticky")
brazos.lua:
-- Variables
local user = os.getenv("USER")
local scratch_base = pathJoin("/fdata", "scratch")
-- Adds trailing colon which allows man to still search system paths
append_path("MANPATH", "")
-- Set SCRATCH that points to user's /fdata scratch directory
setenv("SCRATCH", pathJoin(scratch_base, user))
-- Requires --force to remove this module
add_property("lmod", "sticky")
Thanks,
- Trey
=============================
Trey Dockendorf
Systems Analyst I
Texas A&M University
Academy for Advanced Telecommunications and Learning Technologies
Phone: (979)458-2396
Email: [email protected]
Jabber: [email protected]
----- Original Message -----
From: "Fotis Georgatos" <[email protected]>
To: [email protected]
Sent: Monday, August 25, 2014 4:09:43 PM
Subject: Re: [easybuild] Getting started with EB - integrating into existing
Lmod environment
Hi Trey,
On Aug 25, 2014, at 6:00 PM, Trey Dockendorf wrote:
They are somewhat uncommon I would guess so once I get to them I'll
try my hand at making easyblocks for them.
Let's recall that, if you manage to provide the reproducible
installation _shell_ scripts,
which use $1 as prefix, it is going to be quite easy for the rest of
the list to assist
(or, bring up yet another interesting issue :)
best,
Fotis
--
echo "sysadmin know better bash than english" | sed s/min/mins/ \
| sed 's/better bash/bash better/' # signal detected in a CERN forum
