Re: Enhancements

[Eric S. <bar...@kn...>]

Mark,

Sorry for the delay in getting back to you; I'm just now getting the
chance to try to implement this.

I would like to try to get some clarification on what you're
suggesting below because I'm not sure what you mean.  Can you help me
understand what you mean by, "...where $flag is either true or false
and determined just prior to this call?"

Perhaps it would work best to explain in more detail what I was
thinking and you can tell me how (or if) your suggestion differs from
mine.  I was thinking that there would be a procedure in the
modulefile something like the following:

	proc ModuleAvail { $flag } {
		$flag = [ file isdirectory /tools/gcc/2.95.2 ]
	}

You'll have to forgive me if there are syntax errors in the above tcl
code; my tcl is not very strong and I'm too lazy to look up the
correct syntax now.  I mean 'flag' to be passed by reference so that
it's value is returned.

How then does this differ from what you are saying?

Thanks for taking the time to comment.

Eric

On Thu, Feb 21, 2002 at 10:49:42AM -0800, Mark Lakata wrote:
> sounds like a good suggestion. I think in keeping with the current calling
> convention that command would be something like
> 
>  module-avail $flag
> 
> where $flag is either true or false and determined just prior to this call. If
> the module-avail is not given in the module, then by default the module is
> assumed to be available (i.e. to be backwards compatible with all existing
> modulefiles).
> 
> examples:
> 
>  module-avail [ file isdirectory /tools/gcc/2.95.2 ]
> 
>  module-avail [ string match [ uname sysname ] "Linux" ]
> 
> 
> The rest of the module would be the same.
> 
> Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
> 
> On Thu, 21 Feb 2002, Eric Stanley wrote:
> 
> > At our site, we have implemented modulefiles in such a way that there
> > is only one set of modulefiles across all platforms.  This reduces the
> > effort required to keep the modulefiles up to date.  In our case the
> > platforms are a couple versions of Solaris and a couple versions of
> > Linux.  This does, however, lead to a problem for which I'd like to
> > suggest a solution and get the list's feedback.
> > 
> > The problem arises when doing a 'module avail' command.  Since all
> > modulefiles are in the modulefiles directory, they are all listed as
> > being available even though not every version of software is installed
> > on every platform.  In the modulefile itself the presence or absence
> > of a particular software package is handled by checking for the
> > existance of the top level directory of the software package similar
> > to the following:
> > 
> >     if { [ file isdirectory /tools/gcc/2.95.2 ] } {
> >     	set gcc_home /tools/gcc/2.95.2
> >         setenv CC gcc
> >         prepend-path PATH ${gcc_home}/bin
> >         prepend-path MANPATH ${gcc_home}/man
> >         prepend-path LD_LIBRARY_PATH ${gcc_home}/lib
> >     } else {
> >         break
> >     }
> > 
> > What I would like to suggest that the 'module avail' command check for
> > the existance of a special procedure with a reserved name in the
> > modulefile.  The procedure might be named something like 'Avail' and
> > would return TRUE if the package was really availble on the platform
> > on which 'module avail' was being run and FALSE otherwise.  If TRUE
> > was returned, 'module avail' would list the modulefile as being
> > available, otherwise it would not.  If no such procedure existed,
> > 'module avail' would use the presence of the modulefile as the only
> > indication that the modulefile was available.
> > 
> > I'd be willing to try to hack in this solution unless we come up with
> > a better one.  Perhaps there is already a good solution and I just
> > don't know about it.
> > 
> > Thanks for your feedback.
> > 
> > Eric
> > 
> 
> 
>