On 01/16/2013 02:59 PM, Riccardo Murri wrote:
Hi all,
On Wed, Jan 16, 2013 at 1:27 PM, Kenneth Hoste <[email protected]> wrote:
So, various options. Again, I'd vote to contribute back goalf updates, but
you can imagine why I would prefer that. ;-)
A side note about building our own "goalf" variant: we tried it this
morning and basically failed.
Apparently, it's not enough to just copy+edit "goalf-1.1.0" into
"goalf-1.1.0GC3", but then we need to provide "1.1.0GC3" modified
versions of a number of packages, where the only modification is
changing the file name and a variable inside the file to read
"1.1.0GC3" instead of "1.1.0". In fact, the "f/flex" directory in
"easyconfigs" contains three different "flex*.eb" where the only
difference is the toolchain name...
Is this correct/expected?
You can make it work on the command line using
"--try-toolchain=goalf,1.1.0GC3" and giving it goalf easyconfig files
(or make EasyBuild look for them, e.g. using --software-name=flex as well).
We could merge all three flex easyconfigs into a single one using a
feature that allows to define "blocks" (not easyblocks, we'll reword
that to section or somesuch somtime in the future to avoid confusion) in
easyconfig files, but that has implications for the robot dependency
resolver (which depends on filenames and single toolchains in .eb files).
You don't have to change the filename of the easyconfig file, except
when you want to use the robot feature.
Does that answer all your questions?
K.
Thanks,
Riccardo
--
Riccardo Murri
http://www.gc3.uzh.ch/
Grid Computing Competence Centre
University of Zurich
Winterthurerstrasse 190, CH-8057 Zürich (Switzerland)
Tel: +41 44 635 4222
Fax: +41 44 635 6888
