On 11/03/16 18:01, André Gemünd wrote:
Hi Kenneth,
But first of all: welcome to the wonderful world of EasyBuild! :-)
Thanks. :)
What you may be look for is configuration files, i.e.
http://easybuild.readthedocs.org/en/latest/Configuration.html#configuration-file-s
EasyBuild will pick up configuration files in /etc/easybuild.d/*.cfg, among
other locations, so maybe you want to specify configuration options specific to
the system there?
Yep, I've seen that. But what I'd actually would like to do is configure
EasyBuild system-independent. :)
Its installed on a share, and I'd like to use a global configuration file.
Well, then you can make sure the exact same
/etc/easybuild.d/defaults.cfg config file is available everywhere?
I tried to install intel-2015b.eb today, and found that it uses e.g. ccomp
2015.3.187, while intel already provides 2015.6.233. Now, should I copy the
existing easyconfig from folder A to folder B, edit it, then run the install?
For that, do I really need to search the
lib/python-xy/site-packages/xyz-xyz-py2.7-egg/easybuild/easyconfigs/letter/name/version
path, or is there some more comfortable way? It seems a bit cumbersome. Then,
is the robot path what I'm looking for for folder B? I'm a bit confused by the
name robot path, if its actually the easyconfig path?
Or do you guys work on a git clone of the easyconfig repo as robot path? I guess
this would make pull requests for changes a lot easier.
Different people have different approaches, you'll need to figure out what works
best for you.
Again, the documentation should help, cfr.:
http://easybuild.readthedocs.org/en/latest/Using_the_EasyBuild_command_line.html#controlling-robot-search-path
Okay, although that doesn't really explain why the easyconfig path is called
robot path?
That's a historical thing, it's just how we ended up naming it...
That's even before we started using .eb as extension for easyconfig
files (or even before we started naming them as such...).
I guess I will try to point the robot path to a git clone of the latest
easysconfig repository if that makes any sense.
It does make sense, if you want to pick up the latest stuff.
Be careful with following the 'develop' branch closely though, as new
easyconfigs may require new features from the framework/easyblocks
repository...
What most people do is maintain their own stack of easyconfig files on
top of the ones shipped with EasyBuild, to deal with site-specific
customizations and/or in-house easyconfigs.
Like Alan mentioned, we have more recent compositions of the Intel toolchain
there, and
there's also two open pull requests for the very latest versions (2016
update2), one on
top of GCC 4.9.3 (https://github.com/hpcugent/easybuild-easyconfigs/pull/2620),
one on top
of GCC 5.3.0 (https://github.com/hpcugent/easybuild-easyconfigs/pull/2524).
Great. And what do people do when Intel releases Update 3 shortly after? As I
said, its probably more a question of best-practice. Do you skip these
versions? Or just update them without using EasyBuild? And if there is an
EasyConfig using an older release, do you stay with the one thats referenced in
the file for better reproducability (or some other reason), or simply modify it?
We don't modify the versions of dependencies in existing easyconfig
files (unless there's a very good technical reason).
Someone looks into creating a new version of the required easyconfigs,
and (hopefully) submits a pull request for them.
Then someone reviews/tests that PR, and it gets merged (into the
'develop' branch), and included in the next EasyBuild release.
regards,
Kenneth
