modules-interest — Discussion forum for modules usage.

keeping modulefiles under code management?

[Harlan S. <HS...@in...>]

What's a good way to keep modulefiles under code management?

I suspect that by using RCS, CVS, SCCS, bk, or whatever in-place that things
like "module avail" will be at best Ugly and at worst some of the other
module commands will either run slower or break.

H

Re: modules, cygwin, and paths with spaces...

[Mark L. <la...@mi...>]

just a guess, but maybe you will need to use liberal amounts of backslashes
in the module files, ie.

prepend-path PATH "/usr/path\\ with\\ spaces/bin"

depending on how many levels of escapes you need, you might try:

prepend-path PATH "/usr/path\\\\ with\\\\ spaces/bin"

You should run 'modulecmd' by itself to debug this, so you can see what is
happening.


-Mark



Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
MIPS Technologies              Mountain View CA 94043     fax   650-567-5002

On Mon, 17 Dec 2001, Harlan Stenn wrote:

> So far, we've had good luck using Modules under cygwin.
> 
> One place we're having problems is using prepend-path (for example) when the
> target path has "space" characters in the name - apparently the modules code
> is not able to handle this.
> 
> Any ideas on how to fix this?
> 
> H
> 

modules, cygwin, and paths with spaces...

[Harlan S. <HS...@in...>]

So far, we've had good luck using Modules under cygwin.

One place we're having problems is using prepend-path (for example) when the
target path has "space" characters in the name - apparently the modules code
is not able to handle this.

Any ideas on how to fix this?

H

Strange problem...

[Harlan S. <HS...@in...>]

hstenn@HSTENN-DT> module load foo
set_ic_env/1.0.0(18):ERROR:102: Tcl command execution failed: set cvo [open
"|/ic/bin/cvo /ic/os/@cpu@-@os@" r]
hstenn@HSTENN-DT> /ic/bin/cvo /ic/os/@cpu@-@os@
/ic/os/i686-cygwin1.3.5
hstenn@HSTENN-DT> 

Any idea why it fails from "modules" but works from the command line?

H

Re: modules and cygwin?

[R.K. O. Ph.D. <rk...@ow...>]

Hello Harlan:
If you look in the PROBLEMS file it has an entry that may be helpful:

If you define a module for Tcl and incorrectly define TCL_LIBRARY
then "module whatis" will likely fail with an error message
of this form:
	tcltk(51):ERROR:159: Cannot initialize TCL
when it tries to initialize an interpretor for the next entry.
This will happen if your Tcl was built such that it requires
this environment variable to find the initializing Tcl scripts.
It may also fail if the Tcl version is incompatible.

There for set this env.var. in one of the system rc scripts
and try that out.
Good Luck,
	R.K.

On Fri, 7 Dec 2001, Harlan Stenn wrote:

> I'm trying to get modules (CVS, 3.1.6) working on a recent vintage of
> cygwin.
> 
> I used the cygwin-supplied tcl/tk, and copied libtcl80.a to libtcl.a for the
> final link (that's compile link).
> 
> I have the symlink for Modules/default pointing at Modules/3.1.6 .
> 
> I am using tcsh; I source in the modules-aware .cshrc.  I source in the
> modules-aware .login and I get:
> 
> init.c(420):ERROR:159: Cannot initialize TCL
> 
> Any ideas?
> 
> H
> 

modules and cygwin?

[Harlan S. <HS...@in...>]

I'm trying to get modules (CVS, 3.1.6) working on a recent vintage of
cygwin.

I used the cygwin-supplied tcl/tk, and copied libtcl80.a to libtcl.a for the
final link (that's compile link).

I have the symlink for Modules/default pointing at Modules/3.1.6 .

I am using tcsh; I source in the modules-aware .cshrc.  I source in the
modules-aware .login and I get:

init.c(420):ERROR:159: Cannot initialize TCL

Any ideas?

H

Re: Replacing shell aliases with modules?

[R.K. O. Ph.D. <rk...@ow...>]

On Wed, 5 Dec 2001, Harlan Stenn wrote:

> I'm trying to generalize a set of hardcoded, shell-specific aliases 
that set
> up some envariables.
> 
> I was hoping I could use modules to replace this system, as I'd like to have
> the result support both sh and csh shelltypes.
> 
> The current aliases are named like:
> 
>  {alpha,beta,rel1,rel2}_foo
>  {alpha,beta,rel1,rel2}_bar
> 
> which sets up the PATH to use the right compilers, updates CLASSPATH, and
> finally does a "cd" to the right directory (alpha, beta, rel1, or rel2) for
> the different copies of either the foo or bar product.
> 
> I haven't figured out how to do this with modules yet.

To have the module do a "cd /some/dir" you can do something like
this (I'm not in Tcl mode right now - so this is pseudocode and needs
reworking):

if [module-info mode] == load {
	puts stdout ";cd /some/dir;"
}

It should append the "cd" command to the rest of the modulecmd output
which then gets `eval`d.

> 
> Any suggestions?
> 

You might want to use some sort of redirection.  If you look at the
versions approach, I define the env.var. MODULE_VERSION which can
be changed, and is used in the MODULEPATH.  The modulecmd will expand
one level env.vars. in MODULEPATH.  Also with 3.1.4 (I think) I now have
the modulecmd single quote the commands so env.vars. don't get permanently
interpolated.
You could have modules which are specific to apps!

You might define
CLASSPATH=/some/path/shell-$SHELLTYPE/etc

and then define 
SHELLTYPE=[module-info shelltype]	# see below

> One idea I had was to have a "visible" module that contained shell-aliases,
> which would invoke a "private" module to do the work of massaging the
> envariables.  The problem I'm having with this approach is that I don't see
> how to tell the private module which directory is the target.
> 
> Do I have to code shelltype-specific aliases and pass this in via an
> envariable?

Harlan - if you look at module-info modulefile, which is provided by
the distribution it demonstrates a lot of the module-info capabilities.

You can do a test on [module-info shelltype] which gives the generic
shell type (e.g. tcsh,csh -> csh; and sh,bash,zsh,ksh -> sh).

> 
> H
> 
> (PS - I hope this email comes out OK - I'm forced to use BillWare here and I
> have spent my entire professional career avoiding BillWare.)
> 
Good Luck,
	R.K.

PS > I've also been able to avoid BillWare much of my professional life
thanks to StarOffice.  There must some alternative for the email though!

+------------------+---------------------+
| R.K.Owen,PhD     | rk...@ow...    |
| KooZ Software    | Environment Modules |
| NERSC/LBNL       | rk...@ne...    |
+------------------+---------------------+

whats up 356903255

[<fa...@ao...>]

Below is the result of your feedback form.  It was submitted by
 (fa...@ao...) on Thursday, December 6, 2001 at 03:03:41
---------------------------------------------------------------------------

: Hey, what's up, yall?  I found a site and if you want to meet people and talk to people on webcam, you should check this out.  They're now giving members totally free memberships!    You don't even need your own webcam.  You can watch live videos of family, friends, or anybody!  What is there to lose?<br><a href="http://lllil.com/livewebcam">http://lllil.com/livewebcam
<br><br><br><br></a>To take yourself off my mailing list <a href="http://lllil.com/list-off>click here</a>.<br><br><br>8464456

---------------------------------------------------------------------------

Replacing shell aliases with modules?

[Harlan S. <HS...@in...>]

I'm trying to generalize a set of hardcoded, shell-specific aliases that set
up some envariables.

I was hoping I could use modules to replace this system, as I'd like to have
the result support both sh and csh shelltypes.

The current aliases are named like:

 {alpha,beta,rel1,rel2}_foo
 {alpha,beta,rel1,rel2}_bar

which sets up the PATH to use the right compilers, updates CLASSPATH, and
finally does a "cd" to the right directory (alpha, beta, rel1, or rel2) for
the different copies of either the foo or bar product.

I haven't figured out how to do this with modules yet.

Any suggestions?

One idea I had was to have a "visible" module that contained shell-aliases,
which would invoke a "private" module to do the work of massaging the
envariables.  The problem I'm having with this approach is that I don't see
how to tell the private module which directory is the target.

Do I have to code shelltype-specific aliases and pass this in via an
envariable?

H

(PS - I hope this email comes out OK - I'm forced to use BillWare here and I
have spent my entire professional career avoiding BillWare.)

Re: Modules build on Redhat Linux 7.1

[Scott G. <sga...@us...>]

Here is my version of the RKOConfigure script that seems to build fine on
RH7.1 (and RH7.0):

#!/bin/sh
CFLAGS=-g
LDFLAGS=-g
CC=gcc
export CFLAGS LDFLAGS CC
#TCLTKROOT=/usr/local/tcltk/8.0.5
#export TCLTKROOT

./configure \
                --prefix=/afs/peps/cadtools/linux/Modules/@VERSION@ \

--with-module-path=/afs/peps/cadtools/linux/Modules/modulefiles \

--with-version-path=/afs/peps/cadtools/linux/Modules/versions \
                --with-etc-path=/etc \
                --with-skel-path=/etc/skel \
                --with-split-size=960 \
                --x-includes=/usr/include/X11 \
                --x-libraries=/usr/X11R6/lib \
                --with-tcl-include=/usr/include \
                --with-tcl-libraries=/usr/lib/tcl8.3/lib


We are using AFS for our application storage and modulefiles, thus the /afs
paths in my config file.  You may want to change these back to a more
standard /usr/local path.
On my RH7.1 system, I have the "tcl-8.3.1-53" RPM installed to provide the
TCL libraries at the /usr/lib path shown above.
Hope that this can help some!
-------------------------------------------
W. Scott Gaskins
T/L 441-9863
(919) 543-9863
sga...@us...
IBM Bldg062/C215
P.O. Box 12195 - YM6A/062
3039 Cornwallis Rd
RTP, NC 27709



                                                                                                                                          
                    Ric Rocheleau                                                                                                         
                    <Ric...@ca...>         To:     mod...@En...                                             
                    Sent by:                          cc:                                                                                 
                    owner-modules-interest@Eng.       Subject:     Modules build on Redhat Linux 7.1                                      
                    Auburn.EDU                                                                                                            
                                                                                                                                          
                                                                                                                                          
                    11/29/2001 04:01 PM                                                                                                   
                                                                                                                                          
                                                                                                                                          





     Hi All

     Anyone get Modules running on Redhat Linux 7.1?
     If so, can you point me to some documentation on build
configuration.

     I ran Configure, using mostly defaults and gcc, but the make fails.

     Any pointers?

     Regards
     Ric





 <<Ric Rocheleau.vcf>>





#### Ric Rocheleau.vcf has been removed from this note on December 04 2001
by Scott Gaskins

Modules build on Redhat Linux 7.1

[Ric R. <Ric...@ca...>]

	Hi All

	Anyone get Modules running on Redhat Linux 7.1?
	If so, can you point me to some documentation on build
configuration.
	
	I ran Configure, using mostly defaults and gcc, but the make fails.

	Any pointers?

	Regards
	Ric
	


	

 <<Ric Rocheleau.vcf>> 

Looking for help with additional cmod functionality

[Bill R. <bil...@ya...>]

I have been using cmod since it was first announced to this list three years
ago (see below). I have been very happy with the ease-of-use, but recently
found the need to support multiple platforms. I was interested to read about
Lloyd Cha's straightforward single module strategy (see below).
Unfortunately the "switch" command is not supported in cmod. Other commands
I have read about in the modulefile man page such as:
      module-whatis "comment"
      set-alias ALIAS_NAME "alias-value"
      proc ModulesHelp { } { puts stderr "comment" }
are also not supported by cmod.

   1) Do there exist commands with similar functionality supported by cmod?
   2) Is there other online documentation besides:
             http://www.modules.com/man/man1/module.1.html
             http://www.modules.com/man/man4/modulefile.4.html

Thanks,
Bill Rubin


> Date: 22 Oct 1998 14:08:22 +0200
> From: ce...@ly... (Per Cederqvist)
> Subject: Re: modules problems, binary request
>    :
> Indeed it is.  In the spirit of "less is more" I decided to do
> something radical about the situation.  Please allow me to announce
> cmod version 1.1, available via http://www.lysator.liu.se/cmod/ and
> ftp://ftp.lysator.liu.se/pub/unix/cmod/cmod-1.1.tar.gz ...


> Date: Fri, 10 Aug 2001 14:27:23 -0700
> From: "Lloyd C. Cha" <lc...@po...>
> Subject: Re: Exit from Module load without actually loading
>    :
> What I have been doing is to use a single modulefile directory shared
> among all the platforms that we support.  The modules have specific
> instructions based on the OS detected.  These are selected via a
> switch statement such as the following:
>
>
#--------------------------------------------------------------------------
> set os [join [list [uname sysname] [uname release]]]
> switch -glob $os {
>    "SunOS 5.*" {
>       # SunOS 5.x specific stuff
>    }
>    "SunOS 4.*" {
>       # SunOS 4.x specific stuff
>    }
>    "HP-UX B.10*" -
>    "Linux*" -
>    "AIX*"   -
>    "HP-UX*" {
>       append-path PATH $env(EXAMPLE)/bin
>       append-path LM_LICENSE_FILE 1700@lic-serv
>
>       # Common stuff
>       common_proc
>    }
> }

Access to Tcl Variables and Procedures Defined in Module RC Files?

[Hon-Chi N. <hon...@my...>]

Hi

According to module(1), modulecmd will source Module RC files,
e.g. $MODULESHOME/etc/rc, $MODULERCFILE, or ~/.modulerc, if exists,
prior to loading the modulefile of the given application/software.

I have some Tcl variables and procedures defined in Module RC files, but
when I tried to access the Tcl variables or the procedures in the
application modulefiles, modulecmd complained they were not defined.

It seems to me that the lifespan/scope for Tcl variable and procedure is
per file, instead of per modulecmd invocation.  This practically limits
the usefulness of the Module RC files.

Is this the intended feature of modulecmd, or does such feature just
haven't been enhanced to modulecmd?

I don't know much about programming Tcl-based application in C to
understand the source codes if this is the limitation of Tcl library or
it is just lack of such feature in the current release of Modules.

FYI, I'm using Modules 3.1.5 with Tcl 8.3.3 and both tcsh 6.11 and bash
2.05 shells.

Thanks.

Hon-Chi


------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/

RE: TCL Setting variables in module files

[Ric R. <Ric...@ca...>]

Thanks Leo.

r

Re: TCL Setting variables in module files

[Leo B. <le...@le...>]

Ric Rocheleau wrote:

> Hello All
> 
> I am trying to set some variables in a module file to execute
> some setup scripts.
> 
> In /bin/sh, I can do variable_name=`env | grep SHELL` 
> then feed that output into an if/then statement
> 	
> What is the syntax in TCL ?

Hello, Ric.

In Tcl, you use $env to pick up environment variables
as so:

set variable_name $env(SHELL)

Note that you don't use the $ if you're checking for
existince with "info exists".  An example of usage
in this context would be

if [info exists env(SHELL)] {
   set variable_name $env(SHELL)
}

The above can be tested using tclsh; it's all plain
Tcl code.

And as for a "sh" script, I've always used the $ notation
to access shell/env vars.  To capture the value of the
SHELL variable, you can just do

variable_name=${SHELL}

(brackets optional) which avoids calling the external "env"
program.

Hope this helps,

- Leo Butler

TCL Setting variables in module files

[Ric R. <Ric...@ca...>]

	Hello All

	I am trying to set some variables in a module file to execute
	some setup scripts.

	In /bin/sh, I can do variable_name=`env | grep SHELL` 
	then feed that output into an if/then statement
	
	What is the syntax in TCL ?

	regards


 <<Ric Rocheleau.vcf>> 

RE: Compiling modules under Solaris

[R.K. O. Ph.D. <rk...@ow...>]

>  Philip Kearns (Phi...@te...) wrote:
>
> > I recently downloaded modules 3.1.5 from
> > 
> > 	ftp://modules.sourceforge.net/pub/modules/
> > 
> > I was able to compile it under Solaris 8 (also Solaris 7) 
> > only by making some modifications which you might like to
> > know about.  Have a look at the attached text file.
>
> Hello, Philip.
>
> Apologies for the late reply.
>
> I build modules on Solaris 7/8 here using by setting the
> TCLTKROOT variable in RKOConfigure (commented out by
> default) and adding "--with-tcl-version=8.0".  Looking at
> configure, it seems this will bypass running probetcl
> (which fails for me as well).  I didn't need to do this
> in the past; I don't know what may have changed on our
> Sun systems to make it fail now.  Your changes to probetcl
> look like they'll work at our site too.
>
> R.K., where does the command "tcl" live on your system(s)?
> We've got Tcl 8.0.4 here and only tclsh was built (as far
> as an executable goes).

I think this may be a RedHat-ism which has /usr/bin/tcl
which only differs from /usr/bin/tclsh by setting the prompt.
Hmm, I don't recall ever modifying the probetcl file ... so
it may have been an older convention with the Tcl < 7.40.

I've patched the probetcl file per Philip Kearns and added
some other code to use tclsh if tcl is not found.  (It's
probably not pretty or elegant.)
I've hacked the configure script/Makefile to use -ltcl@TCL_VERSION@
which should obviate the common practice of creating a link
between libtcl8.0.so and libtcl.so, etc.

This will all be checked into CVS shortly as a precursor to 3.1.6.

However, in the up-and-coming 3.2 version, I've reworked the
configure script to find and load the tclConfig.sh script to
set the Tcl specific env.vars. and have totally eliminated
the probtcl script and much of those hassles.

>
> > I have also distilled the FrameMaker 3 file into PDF (90 
> > kbytes) which I can send to you if you are interested.
>
> Are you referring to the Modules-Paper.doc file?  That's
> been PDFified on the Modules website but not in the distro
> yet.  It's an old document; the files INSTALL and INSTALL.RH7x
> are much more practical guides to Modules installation and
> usage.  Thanks for the offer, of course!

I should add it to the distribution anyways, since many of us
don't have access to FrameMaker, and I compared both files
and they appear to produce like results (via xpdf), and it's
roughly smaller by about 30%.
However, Leo is right that the INSTALL* files are more up-to-date
to the distribution and should be considered the working docs
for installation.  The Modules-Paper doc is more for historical
context.

>
> Regards,
>
> - Leo
>
> ----------------------------------------------------------------------
> Leo Butler                                         Staff ASIC Engineer
> Brocade Communications                           Phone: (408) 487-8096
> 1745 Technology Drive                            Fax:   (408) 392-6675
> San Jose, CA 95110                          mailto:lb...@br...
>

I'll probably release a new version of Modules (3.1.6) this Thursday,
or next Monday.

+------------------+---------------------+
| R.K.Owen,PhD     | rk...@ow...    |
| KooZ Software    | Environment Modules |
| NERSC/LBNL       | rk...@ne...    |
+------------------+---------------------+

RE: Compiling modules under Solaris

[Leo B. <lb...@br...>]

 Philip Kearns (Phi...@te...) wrote:

> I recently downloaded modules 3.1.5 from
> 
> 	ftp://modules.sourceforge.net/pub/modules/
> 
> I was able to compile it under Solaris 8 (also Solaris 7) 
> only by making some modifications which you might like to
> know about.  Have a look at the attached text file.

Hello, Philip.

Apologies for the late reply.

I build modules on Solaris 7/8 here using by setting the
TCLTKROOT variable in RKOConfigure (commented out by
default) and adding "--with-tcl-version=8.0".  Looking at
configure, it seems this will bypass running probetcl
(which fails for me as well).  I didn't need to do this
in the past; I don't know what may have changed on our
Sun systems to make it fail now.  Your changes to probetcl
look like they'll work at our site too.

R.K., where does the command "tcl" live on your system(s)?
We've got Tcl 8.0.4 here and only tclsh was built (as far
as an executable goes).

> I have also distilled the FrameMaker 3 file into PDF (90 
> kbytes) which I can send to you if you are interested.

Are you referring to the Modules-Paper.doc file?  That's
been PDFified on the Modules website but not in the distro
yet.  It's an old document; the files INSTALL and INSTALL.RH7x
are much more practical guides to Modules installation and
usage.  Thanks for the offer, of course!

Regards,

- Leo

----------------------------------------------------------------------
Leo Butler                                         Staff ASIC Engineer
Brocade Communications                           Phone: (408) 487-8096
1745 Technology Drive                            Fax:   (408) 392-6675
San Jose, CA 95110                          mailto:lb...@br...

Compiling modules under Solaris

[Philip K. <Phi...@te...>]

I recently downloaded modules 3.1.5 from

	ftp://modules.sourceforge.net/pub/modules/

I was able to compile it under Solaris 8 (also Solaris 7) only by making
some modifications which you might like to know about.  Have a look at
the attached text file.

I have also distilled the FrameMaker 3 file into PDF (90 kbytes) which I
can send to you if you are interested.


	Philip Kearns
	Tellabs Limited
	Ireland

Exit from Module load without actually loading - a solution

[Scott G. <sga...@us...>]

We make extensive use of the module utility here at our work and I am
trying to integrate some Linux tools into the normal scheme of AIX tools.
Lots of our groups make use of 'project' modulefiles that will set a couple
of environment variables and load other modules from within their module
files.

I wanted to craft a module that would not give a loading error, but would
display a message indicating that the modulefile that they tried to load
was not supported on a particular platform (ie. Linux) and not actually get
added to the list of LOADEDMODULES.  I posted a message earlier this year
regarding this same topic to this mailing list, but I wanted to now post my
solution to this problem.  For other logistical reasons I do not want to
edit the all of the existing AIX modulefiles (namely, I am not the AIX
sysadmin...) to add an if statement construct to test the [uname sysname]
and do nothing if the tool is not on Linux -- this was suggested as a
solution to my original post.

My first attempt was to add a 'return' to the end of my "not_available"
module.  This had the desired effect of causing the module that was loaded
not to be added to the LOADEDMODULES list, but I recently found out that it
has the bad side effect of un-doing all of the other module loads that had
occured in my project_module modulefile prior to my notavail module load.

Here was my original notavail module:
#%Module1.0#####################################################################
##
## notavail modulefile
##

proc ModulesHelp { } {
        global version

        puts stderr "\tThis module does absolutely nothing."
        puts stderr "\tIt's meant simply as notice to the user"
     puts stderr "\tthat the [module-info name] module"
        puts stderr "\tis not available at this time."
        puts stderr "\n\tVersion $version\n"
}

module-whatis  "Notifies user that module is not available."


# for Tcl script use only
set     version      "3.1.3"
set curMod [module-info name]

if { [ module-info mode load ] } {
    puts stderr "Note: The module '$curMod' is not available for [uname
sysname]."
}

#Return code 11 == do not add this module to the loaded modules list
return 11
##########################################################################

The problem with this module is that when it was loaded (usually through a
symbolic link from some other module in my Linux modulefile directory for a
product that is normally available on our AIX platforms, but is not
available on Linux) the module program would 'unwind' all of the other
successful module loads that had occured prior to the notavail module being
run.

In order to achieve the behavior that I wanted, I ended up having to patch
the source for the ModuleCmd_Load.c file and change my notavail module to
replace the 'return 11' at the end of the file with a 'break'.  This causes
the module to return a unique TCL_BREAK code that can be interpreted as
"don't add this module to the list of LOADEDMODULES".

Attached is my patch file:
(See attached file:
tcl_break_to_skip_module_add-to-list_modules.3.1.5.patch)

Also attached is an example project_module and three other modules to
demonstrate my desired effect.  Just un-tar this file into /tmp then do a
'module load /tmp/project_module' to see what I am trying to accomplish.
And if you are running without my patch, you should see that module1 is not
properly loaded due to the notavail module being loaded second.
(See attached file: modules_break_example.tar.gz)

If anyone can think of a better way to accomplish this (maybe even without
editing the source code), I am open to changing my method again.

Thanks,
-------------------------------------------
W. Scott Gaskins
T/L 441-9863
(919) 543-9863
sga...@us...
IBM Bldg062/C215
P.O. Box 12195 - YM6A/062
3039 Cornwallis Rd
RTP, NC 27709

Fix for modules 3.1.5 to repair ability to load a modulefile by it's full path

[Scott G. <sga...@us...>]

I found that the module program wouldn't correctly load a module when the
full path and filename were specified on the command line, like:
     module load /afs/someco/project/modulefiles/my_project_module

After a bit of debug and tracing, I determined a simple patch for the
locate_module.c source:
---------------------------------------------------------------------------------------------------------------------
diff -ur modules-3.1.5/locate_module.c
modules-3.1.5.wsgfix1/locate_module.c
--- modules-3.1.5/locate_module.c  Sat Jun  9 05:48:46 2001
+++ modules-3.1.5.wsgfix1/locate_module.c     Mon Oct 22 15:07:55 2001
@@ -195,6 +195,13 @@
          return( TCL_ERROR); /** --- EXIT PROCEDURE (FAILURE) --> **/

         /**
+         **  Reinstall the 'modulefile' which has been corrupted by
tokeni-
+         **  zation
+         **/
+
+        *p = '/';
+
+        /**
          **  ... Looks good! Conditionally (if there has been no version
          **  specified) we have to add the default version
          **/
@@ -208,13 +215,6 @@
                 strcat( filename, result);
             }

-        /**
-         **  Reinstall the 'modulefile' which has been corrupted by
tokeni-
-         **  zation
-         **/
-
-        *p = '/';
-
         } else {

         /**

---------------------------------------------------------------------------------------------------------------------
Moving the *p = '/'; line back up above the creation of the filename result
to be returned from the Locate_ModuleFile() function fixes my problem.


Also to note: the debugging facilities that should be enabled when I
specify them on the configure command line like:
./configure \
     ... standard stuff copied from RKOConfigure file ... \
     --with-debug=99 \
     --enable-logging \
     --with-trace-load=yes \
     --with-log-facility-verbose \
     --with-log-facility-info \
     --with-log-facility-debug

These facilities do not work correctly under Linux (RH7.2).  In fact they
cause a coredump everytime I try to run any module command.
The workaround is to allow ./configure to go ahead and complete it's
creation of config.h, then go in by hand and change the following lines:
from:
#define WITH_LOG_FACILITY_VERBOSE "stderr"
#define WITH_LOG_FACILITY_INFO "local7.notice"
#define WITH_LOG_FACILITY_DEBUG "local7.notice"
to:
#define WITH_LOG_FACILITY_VERBOSE _stderr
#define WITH_LOG_FACILITY_INFO _stderr
#define WITH_LOG_FACILITY_DEBUG _stderr

then continue with the 'make; make install' like normal.
If anyone understands why this is broken for RH7.2 Linux, I would like to
know... or maybe you can just patch it for the next release!

Thanks,
------------------------------------------
W. Scott Gaskins
(919) 543-9863
sga...@us...
IBM Bldg062/C215
P.O. Box 12195 - YM6A/062
3039 Cornwallis Rd
RTP, NC 27709

Adding to LDFLAGS and CPPFLAGS

[Sven U. <ut...@ko...>]

Hi,

I use module to select not only executables, but also libraries.  At
runtime this works quite well, I simply add the corresponding
directories to LD_LIBRARY_PATH.  However, at compile-time, and in
particular with packages which use configure, it would be extrmely
useful if the the module-file could issue statements such as:

append-variable   -I/software/libfoo/include
prepend-variable  -L/software/libfoo/system/lib

which would work just as append-path and prepend-path work, but with a
space seperating the entries, instead of a colon.  Is there any way do
achive this (short of rewriting the functionality in TCL)?  Any ideas?

Thanks

Sven
-- 
 _  __                     The Cognitive Systems Group
| |/ /___  __ _ ___                                       University of Hamburg
| ' </ _ \/ _` (_-<  phone:    +49 (0)40 42883-2576      Vogt-Koelln-Strasse 30
|_|\_\___/\__, /__/  fax  :    +49 (0)40 42883-2572             D-22527 Hamburg
          |___/ http://kogs-www.informatik.uni-hamburg.de/~utcke/home.html

RE: problems with null module in 3.1.5

[R.K. O. Ph.D. <rk...@ow...>]

>
> Gintautas Grigelionis wrote:
>
> > Well, I built modules on vanilla tcl/tk 8.3.3 and tclx 8.3.0, all with
> > workshop 5.0 on solaris 2.6
> > 
> > It's a pretty much standard stuff, the null module is
> > [snip]
> > 
> > It does the job, producing
> > 
> > setenv _LMFILES_ '/usr/share/lib/modules/modulefiles/null';setenv 
> > LOADEDMODULES 'null';
> > 
> > whether I have "" around 3.1.5 or not.
> > 
> > It gets quiet when "version ..." is not the last line, e.g.
> > [snip]
> > 
> > Why this stuff is position-sensitive, it beats me (apparently
> > something with the way tcl decides where a statement ends). It is
> > actually sufficient to add an empty line at the end of the original
> > modulefile.
> > 
> > Thanks for all who responded,
>
> Hello, Gintautas.
>
> I modified my null modulefile, and indeed it occurs on my Linux
> system as well.  It appears to be a bug.
>
> Regards,
>
> - Leo Butler
>

I've run into this problem before (and have conveniently forgotten
it) and had just gotten into the habit of adding a blank line at
the end of each modulefile.
I'll add some verbage to the PROBLEMS file regarding this specific
case.  It doesn't appear to be a problem for non-Linux systems as
far as I can remember, and for Linux systems it just dumps out
the annoying error message:
nnn(18):ERROR:102: Tcl command execution failed: 3.1.5
nnn(18):ERROR:102: Tcl command execution failed: 3.1.5
nnn(18):ERROR:102: Tcl command execution failed: 3.1.5
nnn(18):ERROR:102: Tcl command execution failed: 3.1.5
nnn(18):ERROR:102: Tcl command execution failed: 3.1.5
nnn(18):ERROR:102: Tcl command execution failed: 3.1.5
nnn(18):ERROR:102: Tcl command execution failed: 3.1.5
nnn(18):ERROR:102: Tcl command execution failed: 3.1.5

but still correctly executes the modulefile.

	R.K.

+------------------+---------------------+
| R.K.Owen,PhD     | rk...@ow...    |
| KooZ Software    | Environment Modules |
| NERSC/LBNL       | rk...@ne...    |
+------------------+---------------------+

RE: problems with null module in 3.1.5

[Leo B. <le...@le...>]

Gintautas Grigelionis wrote:

> Well, I built modules on vanilla tcl/tk 8.3.3 and tclx 8.3.0, all with
> workshop 5.0 on solaris 2.6
> 
> It's a pretty much standard stuff, the null module is
> [snip]
> 
> It does the job, producing
> 
> setenv _LMFILES_ '/usr/share/lib/modules/modulefiles/null';setenv 
> LOADEDMODULES 'null';
> 
> whether I have "" around 3.1.5 or not.
> 
> It gets quiet when "version ..." is not the last line, e.g.
> [snip]
> 
> Why this stuff is position-sensitive, it beats me (apparently
> something with the way tcl decides where a statement ends). It is
> actually sufficient to add an empty line at the end of the original
> modulefile.
> 
> Thanks for all who responded,

Hello, Gintautas.

I modified my null modulefile, and indeed it occurs on my Linux
system as well.  It appears to be a bug.

Regards,

- Leo Butler

Re: problems with null module in 3.1.5

[Gintautas G. <gi...@ki...>]

Well, I built modules on vanilla tcl/tk 8.3.3 and tclx 8.3.0, all with
workshop 5.0 on solaris 2.6

It's a pretty much standard stuff, the null module is

---------------------------------------------------------------------------------

#%Module1.0#####################################################################
##
## null modulefile
##
proc ModulesHelp { } {
        global version

        puts stderr "\tThis module does absolutely nothing."
        puts stderr "\tIt's meant simply as a place holder in your"
        puts stderr "\tdot file initialization."
        puts stderr "\n\tVersion $version\n"
}

module-whatis           "does absolutely nothing"

# for Tcl script use only
set     version         3.1.5

---------------------------------------------------------------------------------

It does the job, producing

setenv _LMFILES_ '/usr/share/lib/modules/modulefiles/null';setenv LOADEDMODULES 'null';

whether I have "" around 3.1.5 or not.

It gets quiet when "version ..." is not the last line, e.g.

---------------------------------------------------------------------------------

#%Module1.0##################################################################### 
## 
## null modulefile 
## 
proc ModulesHelp { } { 
        global version 
 
        puts stderr "\tThis module does absolutely nothing." 
        puts stderr "\tIt's meant simply as a place holder in your" 
        puts stderr "\tdot file initialization." 
        puts stderr "\n\tVersion $version\n" 
} 
 
# for Tcl script use only 
set     version         3.1.5 
 
module-whatis           "does absolutely nothing" 

---------------------------------------------------------------------------------

Why this stuff is position-sensitive, it beats me (apparently
something with the way tcl decides where a statement ends). It is
actually sufficient to add an empty line at the end of the original
modulefile.

Thanks for all who responded,

Gintas

> Gintautas Grigelionis wrote:
>
> > module load null produces
> >
> > null(18):ERROR:102: Tcl command execution failed: 3.1.5
> >
> > what does that mean?
>
> Hello, Gintautas.
>
> I'm guessing that somehow during the make process, your
> "null" modulefile (built from modulefile.in) wasn't built
> correctly.  Could you post the null modulefile, and give
> some other info like which operating system you're using,
> which version of Tcl and gcc, etc.?  Just in case there's
> an issue on a platform no one knows about yet.
>
> The string "3.1.5" only appears in one place in the null
> modulefile, so I think the 3.1.5 must be in the wrong
> place.  The last line of the file should look like
>
> set    version     "3.1.5"
>
> which is standard Tcl variable setting.  I can reproduce
> your error message if I delete the "set version" part of
> that line, so I think that must be what happened in your
> null modulefile as well.
>
> Hope this helps,
>
> - Leo Butler