On 01/16/2013 12:12 PM, Riccardo Murri wrote:
Hi,
regarding the toolchain version numbering:
On Tue, Jan 15, 2013 at 2:03 PM, Kenneth Hoste <[email protected]> wrote:
If you want to avoid that your version definition of goalf is redefined in a
future release of the easybuild-easyconfigs package, I suggest you just
create your own toolchain (stupid suggestion: mygoalf). You will also need
to make sure that EasyBuild knows about the new toolchain you created (see
https://github.com/hpcugent/easybuild/wiki/Compiler-toolchains).
The other option is to compose an easyconfig file for goalf v1.2.0 (with,
e.g. GCC 4.7.x), and then issue a pull request for it. Then we will include
it in the next release of easybuild-easyconfigs, and EasyBuild will be using
the exact same definition of goalf v1.2.0 as defined by you.
I guess what would be needed is just a convention for locally-modified packages:
- e.g., as Fotis suggested, append letters to the version number: if
you (upstream) agree to only use numbers for the toolchains, then I
can use "1.1.0RM" to name my locally-modified "goalf".
I like that idea. For self-defined toolchains, I'd say it's a safe bet
that we'll stick to number-only version numbers.
- A way to stack search paths for '*.eb' so that local `*.eb` files
override distributed ones. (Sorry I didn't look carefully into the
documentation, so maybe it's already present.)
As you expect, that's already possible.
You can specify a directory to the -r/--robot command line option, to
make EasyBuild look there (first) for easyconfig files.
That would effectively override whatever EasyBuild ships (note: you
don't even have to have easybuild-easyconfigs installed).
So, various options. Again, I'd vote to contribute back goalf updates,
but you can imagine why I would prefer that. ;-)
regards,
Kenneth
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
