|
From: Andy B. <AB...@in...> - 2002-07-26 17:01:11
|
A quick note on versioning (mentioned below)...
When you do a "module load foo", assume you have a directory struct like
below:
Modules
modulefiles
foo
1.0
1.2
1.10
Then the module actually loaded is the "latest". However, the default
version of the modulecmd binary wasn't sorting numerically; thus the above
command would actually load "foo/1.2" instead of "foo/1.10".
The above isn't a problem for most third-party software, because in your
Module scripts you normally load third-party software specifically (i.e.
"module load jdk/1.3" rather than "module load jdk"). However, for internal
software (such as loading the correct module script to set your local
environment for an internal product version), this can and does become a
problem--it certainly was for us.
Harlan Stenn patched the binary to account for this, but I don't know if it
made it into the distro.
Just to be safe, when I'm setting up versions for internal software scripts
I always use leading zeros to indicate versions.
Regards,
Andy
-----Original Message-----
From: David C. Mores [mailto:dav...@ba...]
Sent: Friday, July 26, 2002 11:00
To: modules interest group
Subject: Re: [Modules] Modules setup in cross-platform environments
Stefan Svensson wrote:
> I try to learn how to set up Modules, but I have not yet found any
> documentation on how to set up a cross-platform environment where you have
> different platforms (Solaris, HP-UX, SGI, Linux), os revisions (Solaris
> 5.6, 7, 8; HP-UX 9, 10.20, 11; etc) and, of course, different application
> versions.
>
> Are there any documents on this, does anyone have any experience - or do I
> have to find out the hard way? :-)
Your can use the .version or .modulerc to control which version of an
application
is going to be the default on a particular platform with something like
this:
#%Module
#
# $Id: .version,v 1.7 2002-07-26 10:28:25-04 dmores Exp $
#
##########################################################################
switch -regexp -- [uname sysname].[uname release] {
{ "HP-UX.*" }
{ set ModulesVersion "20.5" }
{ "SunOS.5.*" }
{ set ModulesVersion "25.3" }
}
The 20.5 and 25.3 refer to directories by that name where the .version file
lives - e.g. appname/20.5
and appname/25.3 - where the .version file is in directory appname. The
modulefile for each version
lives in the 20.5 and 25.3 subdirectory. You can also have a .version file
in each subdiretory if you need
more than one modulefile to choose from but want one to be the default.
In modulefiles you can use a similar arrangement to set the environment
based on
the platform type with something like this TCL code fragment:
set TOOL_HOME /home/tool_25.3_a
#------ O/S specific settings
switch -regexp -- [uname sysname].[uname release] {
SunOS.5.* {
append-path PATH $TOOL_HOME/sol/bin
}
HP-UX.* {
append-path PATH $TOOL_HOME/hpux/bin
}
default {
error "The modulefile [module-info name]: is not supported under O/S
[uname sysname].[uname release]"
}
}
This is an arrangement we have been using successfully for the past 10 years
with Modules version 2.2b. Version 3.x still has problems with more than
two directory levels.
Hope this helps you.
Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Modules-interest mailing list
Mod...@li...
https://lists.sourceforge.net/lists/listinfo/modules-interest
|
