modules-interest — Discussion forum for modules usage.

[Modules] question about prepend-path

[wood, b. <woo...@em...>]

In our environment we have several tools (such as gcc) which may show up in
more that one directory on the user's PATH.  I was hoping to use
prepend-path to make sure the correct directory shows up at the front of the
PATH.  But it appears that prepend-path doesn't do anything if the directory
already exists somewhere in the PATH variable.

Is there an easy way to force a directory to the front of a PATH even if
it's already in the PATH elsewhere?  I know I can just use setenv instead of
prepend-path, but I was hoping to avoid duplication of directories.

Example:  Suppose PATH = /bin:/usr/bin:/usr/local/bin, and my module
specifies

          prepend-path PATH /usr/local/bin

          I would like PATH to end up as /usr/local/bin:/bin:/usr/bin

--
bob wood
bw...@em...
508-249-4561

Re: [Modules] How too debug modulefiles?

[Istvan M. <mi...@im...>]

Keith Richling <kg...@ft...> writes:

> Is there a way to get module to print the tcl stack trace when there is
> a error in the tcl script instead of printing a simplified error message
> such as
>
> grid(56):ERROR:102: Tcl command execution failed: package require site

I don't know of a way to get a stack trace but I have been using the
following to get more meaningful error messages:

diff -u -b -B -c -r1.7 cmdModule.c
*** cmdModule.c	29 Apr 2002 21:16:48 -0000	1.7
--- cmdModule.c	14 Oct 2003 16:53:49 -0000
***************
*** 651,657 ****
          result = Tcl_Eval( interp, cmd);
  
  	if( TCL_ERROR == result) {
! 	    ErrorLogger( ERR_EXEC, LOC, cmd, NULL);
  	}
  
  	Tcl_DStringTrunc( &cmdbuf, 0);
--- 651,657 ----
          result = Tcl_Eval( interp, cmd);
  
  	if( TCL_ERROR == result) {
! 	    ErrorLogger( ERR_EXEC, LOC, Tcl_GetStringResult(interp), NULL);
  	}
  
  	Tcl_DStringTrunc( &cmdbuf, 0);

-- 
	Istvan

[Modules] modules update

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

I've updated the TCL version. You will need to grab the CVS version if you want
to test it. I think things are looking pretty good for the TCL version. Please,
someone, beat on it, since I may have introduced a new bug.

1. pulled all references to puts stderr to report/reportWarnings/reportInternalBug.

2. changed the way the g_mode variable is handled. Instead of relying on the
call stack, it now uses an explicit stack, which might solve any problems with
using other namespaces or packages in the modulefiles.

3. removed a bunch of debugging statements.

4. fixed the way errors are handled, giving more meaningful responses.

5. if an error is caught in load, the env/alias settings are NOT updated. for
instance, in a conflict this is important




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

Re: [Modules] Problem with packages in modulecmd.tcl

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

sorry i can't help. someone who is more versed in the details of tcl variable
scopes might be able to fix the problem. or someone can get rid of the g_mode
variable, and replace it with a mechanism that implements dynamic scoping.

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

On Fri, 3 Oct 2003, Keith Richling wrote:

> Yes, we do use/need tcl packages in our existing modulefiles.  We also
> do call module commands from within these packages.  The way that our
> packages are architected would make if very difficult to not call module
> commands.  If we cannot use packages I will need to keep using the C
> implementation.
>
> Keith
>
> Mark Lakata wrote:
> >
> > Yes, this is a problem. I wasn't anticipating the use of packages in the
> > modulefiles.  It assumes that the modulefiles are only 1 deep. The "mode"
> > variable it complains about is taken from the scope of the calling parent of
> > the module.  If you add another layer with the packages, the scope is wrong.
> >
> > I can't think of an easy way to fix this. There was a reason I did it this way,
> > since it allows you to "change" the mode since it is dynamically scoped (sort
> > of like perls "local").  For instance, you could have module "a" have the line
> > "module unload b" inside. When you load module a, module b gets unloaded. So
> > the mode changes from "load" to "unload", but after module b is unloaded it
> > reverts back to "load". By dynamically scoping (with up_var), I can get away
> > with this. I can't use globals for this.
> >
> > Do you really need to use packages?  If you want to use the package, I suggest
> > that you don't use any module commands in the package, and do all the
> > setenv'ing in the main module. You can use function return values or global
> > values to communicate any settings back to the main module, just don't use
> > 'setenv' in the sub package.
> >
> > Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> > MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
> >
> > On Fri, 3 Oct 2003, Keith Richling wrote:
> >
> > > I am using the tcl implementation of modules checked out from cvs with
> > > bash version 2.05b.
> > >
> > > I have a case where setenv is failing with the following error
> > > message:
> > >
> > > ERROR: module: module load test failed. can't read "mode": no such
> > > variable
> > >
> > > I have attached three files that can be used to reproduce this
> > > problem.  Place these files in <some-directory> and then run the
> > > following commands:
> > >
> > >    md use <some-directory>
> > >    md add test
> > >
> > > The failure is occurring on the following line in the file
> > > test_pkg.tcl:
> > >
> > >    setenv TEST_PKG TRUE
> > >
> > > --
> > > Keith Richling                     |  Agilent Technologies
> > > Email: kei...@ag...  |  MS/72
> > > Voice: (970) 288-7903              |  4380 Ziegler Road
> > >   Fax: (970) 288-6580              |  Fort Collins, CO 80525-9790
>

Re: [Modules] Problem with packages in modulecmd.tcl

[Keith R. <kg...@ft...>]

Yes, we do use/need tcl packages in our existing modulefiles.  We also
do call module commands from within these packages.  The way that our
packages are architected would make if very difficult to not call module
commands.  If we cannot use packages I will need to keep using the C
implementation.

Keith

Mark Lakata wrote:
> 
> Yes, this is a problem. I wasn't anticipating the use of packages in the
> modulefiles.  It assumes that the modulefiles are only 1 deep. The "mode"
> variable it complains about is taken from the scope of the calling parent of
> the module.  If you add another layer with the packages, the scope is wrong.
> 
> I can't think of an easy way to fix this. There was a reason I did it this way,
> since it allows you to "change" the mode since it is dynamically scoped (sort
> of like perls "local").  For instance, you could have module "a" have the line
> "module unload b" inside. When you load module a, module b gets unloaded. So
> the mode changes from "load" to "unload", but after module b is unloaded it
> reverts back to "load". By dynamically scoping (with up_var), I can get away
> with this. I can't use globals for this.
> 
> Do you really need to use packages?  If you want to use the package, I suggest
> that you don't use any module commands in the package, and do all the
> setenv'ing in the main module. You can use function return values or global
> values to communicate any settings back to the main module, just don't use
> 'setenv' in the sub package.
> 
> Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
> 
> On Fri, 3 Oct 2003, Keith Richling wrote:
> 
> > I am using the tcl implementation of modules checked out from cvs with
> > bash version 2.05b.
> >
> > I have a case where setenv is failing with the following error
> > message:
> >
> > ERROR: module: module load test failed. can't read "mode": no such
> > variable
> >
> > I have attached three files that can be used to reproduce this
> > problem.  Place these files in <some-directory> and then run the
> > following commands:
> >
> >    md use <some-directory>
> >    md add test
> >
> > The failure is occurring on the following line in the file
> > test_pkg.tcl:
> >
> >    setenv TEST_PKG TRUE
> >
> > --
> > Keith Richling                     |  Agilent Technologies
> > Email: kei...@ag...  |  MS/72
> > Voice: (970) 288-7903              |  4380 Ziegler Road
> >   Fax: (970) 288-6580              |  Fort Collins, CO 80525-9790

Re: [Modules] Problem with packages in modulecmd.tcl

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

Yes, this is a problem. I wasn't anticipating the use of packages in the
modulefiles.  It assumes that the modulefiles are only 1 deep. The "mode"
variable it complains about is taken from the scope of the calling parent of
the module.  If you add another layer with the packages, the scope is wrong.


I can't think of an easy way to fix this. There was a reason I did it this way,
since it allows you to "change" the mode since it is dynamically scoped (sort
of like perls "local").  For instance, you could have module "a" have the line
"module unload b" inside. When you load module a, module b gets unloaded. So
the mode changes from "load" to "unload", but after module b is unloaded it
reverts back to "load". By dynamically scoping (with up_var), I can get away
with this. I can't use globals for this.

Do you really need to use packages?  If you want to use the package, I suggest
that you don't use any module commands in the package, and do all the
setenv'ing in the main module. You can use function return values or global
values to communicate any settings back to the main module, just don't use
'setenv' in the sub package.

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

On Fri, 3 Oct 2003, Keith Richling wrote:

> I am using the tcl implementation of modules checked out from cvs with
> bash version 2.05b.
>
> I have a case where setenv is failing with the following error
> message:
>
> ERROR: module: module load test failed. can't read "mode": no such
> variable
>
> I have attached three files that can be used to reproduce this
> problem.  Place these files in <some-directory> and then run the
> following commands:
>
>    md use <some-directory>
>    md add test
>
> The failure is occurring on the following line in the file
> test_pkg.tcl:
>
>    setenv TEST_PKG TRUE
>
> --
> Keith Richling                     |  Agilent Technologies
> Email: kei...@ag...  |  MS/72
> Voice: (970) 288-7903              |  4380 Ziegler Road
>   Fax: (970) 288-6580              |  Fort Collins, CO 80525-9790

[Modules] Problem with packages in modulecmd.tcl

[Keith R. <kg...@ft...>]

I am using the tcl implementation of modules checked out from cvs with
bash version 2.05b.

I have a case where setenv is failing with the following error
message:

ERROR: module: module load test failed. can't read "mode": no such
variable

I have attached three files that can be used to reproduce this
problem.  Place these files in <some-directory> and then run the
following commands:

   md use <some-directory>
   md add test

The failure is occurring on the following line in the file
test_pkg.tcl:

   setenv TEST_PKG TRUE

-- 
Keith Richling                     |  Agilent Technologies
Email: kei...@ag...  |  MS/72
Voice: (970) 288-7903              |  4380 Ziegler Road
  Fax: (970) 288-6580              |  Fort Collins, CO 80525-9790

Re: [Modules] Problem with ' in variable value

[Keith R. <kg...@ft...>]

The tcl version is getting this correct.

Keith


Mark Lakata wrote:
> 
> I think the c version of the module command is fundamentally buggy when it
> comes to escaping characters.  The method of
> 
>  export foo='abc\'s'
> 
> gets really messy when you deal with very deep nested quotes, since the shells
> don't let you do that. I favor the approach of
> 
>  export foo=abc\'s
> 
> in otherwords, the value is not surrounded by quotes at all, and everything
> funky is escaped with a backslash. That is what the tcl implementation of
> modulecmd.tcl does.
> 
> -mark
> 
> Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
> 
> On Thu, 2 Oct 2003, Keith Richling wrote:
> 
> > I am using module version 3.1.6 with bash version 2.05b
> >
> > I have a case where I need to set the value of a variable that
> > includes a ' (single quote).
> >
> > In bash I can do this as follows:
> >
> >    export ABC="abc's"
> >
> > When I try to do the same thing through module using the following
> > command
> >
> >    setenv ABC {abc's}
> >
> > I get the following error when I load the module:
> >
> >    bash: unexpected EOF while looking for matching `''
> >    bash: syntax error: unexpected end of file
> >
> > Adding backslashes does not help.
> >
> > How can I have a variable value that contains a '?
> >
> > --
> > Keith Richling                     |  Agilent Technologies
> > Email: kei...@ag...  |  MS/72
> > Voice: (970) 288-7903              |  4380 Ziegler Road
> >   Fax: (970) 288-6580              |  Fort Collins, CO 80525-9790
> >
> >
> > -------------------------------------------------------
> > 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
> >
> 
> -------------------------------------------------------
> 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

Re: [Modules] Problem with * in variable value

[Keith R. <kg...@ft...>]

I just checked out the tcl version and I am currently experimenting with
it.

This problem does not exist in the tcl version.

Keith


Mark Lakata wrote:
> 
> It probably has to do with the problem you see in the previous email.
> Do this:
> 
> First get the path to the actual modulecmd binary:
> 
> > which module
> module () {
>         eval `/mips/tools/platinum/envmodule/modulecmd.tcl zsh $*`
> }
> 
> Then run it without eval it:
> 
> > /mips/tools/platinum/envmodule/modulecmd.tcl zsh add test
> . /tmp/modulescript_1504_0
> 
> then look at the produced output to see how the string is being quoted.
> 
> -Mark
> 
> Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
> 
> On Thu, 2 Oct 2003, Keith Richling wrote:
> 
> > I am using module version 3.1.6 with bash version 2.05b
> >
> > I have a case where I need to set the environment variable FILE_GLOB
> > to "*.C *.c *.pl *.rb *.tcl".  So I have a line in my module file that
> > looks like the following:
> >
> >    setenv FILE_GLOB {*.C *.c *.pl *.rb *.tcl}
> >
> > I test this by executing the following (assume that the name of the
> > module that contains the above code is called test):
> >
> >    module add test
> >
> > I then check the value of the variable by running the following command:
> >
> >    env | grep FILE_GLOB
> >
> > And it prints the following:
> >
> >    FILE_GLOB=*.C *.c *.pl *.rb *.tcl
> >
> > So far so good.  I now create files in my current working directory
> > that match each of the above globs, remove the module, add the module,
> > and check the value of the variable.  Here is the commands that I run
> > to do all of this:
> >
> >    for i in C c pl rb tcl; do touch abc.$i; done
> >    module rm test
> >    module add test
> >    env | grep FILE_GLOB
> >
> > Now I get the last line of the above command prints the following:
> >
> >    FILE_GLOB=*.C abc.c abc.pl abc.rb *.tcl
> >
> > My first question is why are all but the first and last *'s expanded?
> >
> > How can I use a * in a value so that it does not get expanded?
> >
> > --
> > Keith Richling                     |  Agilent Technologies
> > Email: kei...@ag...  |  MS/72
> > Voice: (970) 288-7903              |  4380 Ziegler Road
> >   Fax: (970) 288-6580              |  Fort Collins, CO 80525-9790
> >
> >
> > -------------------------------------------------------
> > 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
> >

Re: [Modules] Problem with * in variable value

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

It probably has to do with the problem you see in the previous email.
Do this:

First get the path to the actual modulecmd binary:

> which module
module () {
        eval `/mips/tools/platinum/envmodule/modulecmd.tcl zsh $*`
}


Then run it without eval it:

> /mips/tools/platinum/envmodule/modulecmd.tcl zsh add test
. /tmp/modulescript_1504_0

then look at the produced output to see how the string is being quoted.


-Mark



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

On Thu, 2 Oct 2003, Keith Richling wrote:

> I am using module version 3.1.6 with bash version 2.05b
>
> I have a case where I need to set the environment variable FILE_GLOB
> to "*.C *.c *.pl *.rb *.tcl".  So I have a line in my module file that
> looks like the following:
>
>    setenv FILE_GLOB {*.C *.c *.pl *.rb *.tcl}
>
> I test this by executing the following (assume that the name of the
> module that contains the above code is called test):
>
>    module add test
>
> I then check the value of the variable by running the following command:
>
>    env | grep FILE_GLOB
>
> And it prints the following:
>
>    FILE_GLOB=*.C *.c *.pl *.rb *.tcl
>
> So far so good.  I now create files in my current working directory
> that match each of the above globs, remove the module, add the module,
> and check the value of the variable.  Here is the commands that I run
> to do all of this:
>
>    for i in C c pl rb tcl; do touch abc.$i; done
>    module rm test
>    module add test
>    env | grep FILE_GLOB
>
> Now I get the last line of the above command prints the following:
>
>    FILE_GLOB=*.C abc.c abc.pl abc.rb *.tcl
>
> My first question is why are all but the first and last *'s expanded?
>
> How can I use a * in a value so that it does not get expanded?
>
> --
> Keith Richling                     |  Agilent Technologies
> Email: kei...@ag...  |  MS/72
> Voice: (970) 288-7903              |  4380 Ziegler Road
>   Fax: (970) 288-6580              |  Fort Collins, CO 80525-9790
>
>
> -------------------------------------------------------
> 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
>

Re: [Modules] Problem with ' in variable value

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

I think the c version of the module command is fundamentally buggy when it
comes to escaping characters.  The method of

 export foo='abc\'s'

gets really messy when you deal with very deep nested quotes, since the shells
don't let you do that. I favor the approach of

 export foo=abc\'s

in otherwords, the value is not surrounded by quotes at all, and everything
funky is escaped with a backslash. That is what the tcl implementation of
modulecmd.tcl does.


-mark



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

On Thu, 2 Oct 2003, Keith Richling wrote:

> I am using module version 3.1.6 with bash version 2.05b
>
> I have a case where I need to set the value of a variable that
> includes a ' (single quote).
>
> In bash I can do this as follows:
>
>    export ABC="abc's"
>
> When I try to do the same thing through module using the following
> command
>
>    setenv ABC {abc's}
>
> I get the following error when I load the module:
>
>    bash: unexpected EOF while looking for matching `''
>    bash: syntax error: unexpected end of file
>
> Adding backslashes does not help.
>
> How can I have a variable value that contains a '?
>
> --
> Keith Richling                     |  Agilent Technologies
> Email: kei...@ag...  |  MS/72
> Voice: (970) 288-7903              |  4380 Ziegler Road
>   Fax: (970) 288-6580              |  Fort Collins, CO 80525-9790
>
>
> -------------------------------------------------------
> 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
>

[Modules] Problem with ' in variable value

[Keith R. <kg...@ft...>]

I am using module version 3.1.6 with bash version 2.05b

I have a case where I need to set the value of a variable that
includes a ' (single quote).

In bash I can do this as follows:

   export ABC="abc's"

When I try to do the same thing through module using the following
command

   setenv ABC {abc's}

I get the following error when I load the module:

   bash: unexpected EOF while looking for matching `''
   bash: syntax error: unexpected end of file

Adding backslashes does not help.

How can I have a variable value that contains a '?

-- 
Keith Richling                     |  Agilent Technologies
Email: kei...@ag...  |  MS/72
Voice: (970) 288-7903              |  4380 Ziegler Road
  Fax: (970) 288-6580              |  Fort Collins, CO 80525-9790

[Modules] Problem with * in variable value

[Keith R. <kg...@ft...>]

I am using module version 3.1.6 with bash version 2.05b

I have a case where I need to set the environment variable FILE_GLOB
to "*.C *.c *.pl *.rb *.tcl".  So I have a line in my module file that
looks like the following:

   setenv FILE_GLOB {*.C *.c *.pl *.rb *.tcl}

I test this by executing the following (assume that the name of the
module that contains the above code is called test):

   module add test

I then check the value of the variable by running the following command:

   env | grep FILE_GLOB

And it prints the following:

   FILE_GLOB=*.C *.c *.pl *.rb *.tcl

So far so good.  I now create files in my current working directory
that match each of the above globs, remove the module, add the module,
and check the value of the variable.  Here is the commands that I run
to do all of this:

   for i in C c pl rb tcl; do touch abc.$i; done
   module rm test
   module add test
   env | grep FILE_GLOB

Now I get the last line of the above command prints the following:

   FILE_GLOB=*.C abc.c abc.pl abc.rb *.tcl

My first question is why are all but the first and last *'s expanded?

How can I use a * in a value so that it does not get expanded?

-- 
Keith Richling                     |  Agilent Technologies
Email: kei...@ag...  |  MS/72
Voice: (970) 288-7903              |  4380 Ziegler Road
  Fax: (970) 288-6580              |  Fort Collins, CO 80525-9790

Re: [Modules] How too debug modulefiles?

[Keith R. <kg...@ft...>]

Leo Butler wrote:
> 
> Keith Richling wrote:
> 
> > I am trying to write some modulefiles but it is slow going because I
> > am having difficulty finding errors in my modulefile tcl scripts.  The
> > problem is that I cannot get module to output the tcl stack trace.
> >
> > Is there a way to get module to print the tcl stack trace when there is
> > a error in the tcl script instead of printing a simplified error message
> > such as
> >
> > grid(56):ERROR:102: Tcl command execution failed: package require site
> >
> > This error message tell me to look on line 56 of the "grid" file, but
> > also as the message says, this line is "package require site".  There is
> > nothing wrong with this line.  The real problem is somewhere within the
> > site package, but since the stack trace is missing, it is difficult to
> > pinpoint the exact error.
> >
> > I have tried the -v and -u command line options, but they seem to do
> > nothing.
> 
> Hello Keith,
> 
> Try building modules with the "--with-debug=<level>" switch at
> compile time.  You can lookup what the level values are in
> modules_def.h.  I don't know if this will specifically get you
> the stack trace, as I haven't needed to use it before.
> 
> Some additional information is provided in the README file in
> the distribution.
> 
> Hope this helps,
> 
> - Leo

I tried adding the following configure options

--enable-logging
--with-log-facility-verbose=stderr
--with-log-facility-info=stderr
--with-log-facility-debug=stderr
--with-log-facility-trace=stderr
--with-log-facility-warn=stderr
--with-log-facility-problem=stderr
--with-log-facility-error=stderr
--with-log-facility-fatal=stderr
--with-log-facility-panic=stderr
--with-debug=100

Just using the --with-debug options did not seem to be enough because
logging is disabled by default for debug messges.

Even after I added these options I did not get what I was looking for. 
Here is an example of the output that I now obtain

grid(56):ERROR:102: Tcl command execution failed: package require site
cmdModule.c(667):DEBUG:1:  Result: 'TCL_ERROR'
cmdModule.c(704):DEBUG:3: Exit Execute_TclFile
cmdModule.c(515):DEBUG:1: Execution of '/tmp/grid' failed

I am getting a trace but it is of the c code and not of the tcl script.

-- 
Keith Richling                     |  Agilent Technologies
Email: kei...@ag...  |  MS/72
Voice: (970) 288-7903              |  4380 Ziegler Road
  Fax: (970) 288-6580              |  Fort Collins, CO 80525-9790

RE: [Modules] How too debug modulefiles?

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

Keith Richling wrote:

> I am trying to write some modulefiles but it is slow going 
> because I am having difficulty finding errors in my modulefile
> tcl scripts.  The problem is that I cannot get module to
> output the tcl stack trace.
>
> Is there a way to get module to print the tcl stack trace 
> when there is a error in the tcl script instead of printing
> a simplified error message such as
>
> grid(56):ERROR:102: Tcl command execution failed: package 
> require site
>
>
> This error message tell me to look on line 56 of the "grid" 
> file, but also as the message says, this line is "package
> require site".  There is nothing wrong with this line.  The
> real problem is somewhere within the site package, but since
> the stack trace is missing, it is difficult to pinpoint the
> exact error.
>
> I have tried the -v and -u command line options, but they
> seem to do nothing.

Keith,

Check out the README file in the source distribution.  There
is a "--with-debug=<level>" switch discussed there.  See if
that covers your needs.

Regards,

- Leo

Re: [Modules] How too debug modulefiles?

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

I'm not sure if this is any easier, but I would suggest trying to use the new
tcl version of the module command (modulecmd.tcl) which is in the tcl/ sub dir
of the CVS tree. Since it is written entirely in TCL and considerably (100
times!)  simpler, you should be able to hack it to make it dump stack traces
easily. I'm not a hard core tcl coder, so I don't know the magic incantations
to force dumps like this, but I'm sure you can figure it out...

With the old "c" version, I have no idea, sorry.

-Mark


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

On Thu, 2 Oct 2003, Keith Richling wrote:

> I am trying to write some modulefiles but it is slow going because I am
> having difficulty finding errors in my modulefile tcl scripts.  The
> problem is that I cannot get module to output the tcl stack trace.
>
> Is there a way to get module to print the tcl stack trace when there is
> a error in the tcl script instead of printing a simplified error message
> such as
>
> grid(56):ERROR:102: Tcl command execution failed: package require site
>
>
> This error message tell me to look on line 56 of the "grid" file, but
> also as the message says, this line is "package require site".  There is
> nothing wrong with this line.  The real problem is somewhere within the
> site package, but since the stack trace is missing, it is difficult to
> pinpoint the exact error.
>
> I have tried the -v and -u command line options, but they seem to do
> nothing.
>
> --
> Keith Richling                     |  Agilent Technologies
> Email: kei...@ag...  |  MS/72
> Voice: (970) 288-7903              |  4380 Ziegler Road
>   Fax: (970) 288-6580              |  Fort Collins, CO 80525-9790
>
>
> -------------------------------------------------------
> 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
>

Re: [Modules] How too debug modulefiles?

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

Keith Richling wrote:

> I am trying to write some modulefiles but it is slow going because I
> am having difficulty finding errors in my modulefile tcl scripts.  The
> problem is that I cannot get module to output the tcl stack trace.
> 
> Is there a way to get module to print the tcl stack trace when there is
> a error in the tcl script instead of printing a simplified error message
> such as
> 
> grid(56):ERROR:102: Tcl command execution failed: package require site
> 
> This error message tell me to look on line 56 of the "grid" file, but
> also as the message says, this line is "package require site".  There is
> nothing wrong with this line.  The real problem is somewhere within the
> site package, but since the stack trace is missing, it is difficult to
> pinpoint the exact error.
> 
> I have tried the -v and -u command line options, but they seem to do
> nothing.

Hello Keith,

Try building modules with the "--with-debug=<level>" switch at
compile time.  You can lookup what the level values are in
modules_def.h.  I don't know if this will specifically get you
the stack trace, as I haven't needed to use it before.

Some additional information is provided in the README file in
the distribution.

Hope this helps,

- Leo

[Modules] How too debug modulefiles?

[Keith R. <kg...@ft...>]

I am trying to write some modulefiles but it is slow going because I am
having difficulty finding errors in my modulefile tcl scripts.  The
problem is that I cannot get module to output the tcl stack trace.

Is there a way to get module to print the tcl stack trace when there is
a error in the tcl script instead of printing a simplified error message
such as

grid(56):ERROR:102: Tcl command execution failed: package require site


This error message tell me to look on line 56 of the "grid" file, but
also as the message says, this line is "package require site".  There is
nothing wrong with this line.  The real problem is somewhere within the
site package, but since the stack trace is missing, it is difficult to
pinpoint the exact error.

I have tried the -v and -u command line options, but they seem to do
nothing.

-- 
Keith Richling                     |  Agilent Technologies
Email: kei...@ag...  |  MS/72
Voice: (970) 288-7903              |  4380 Ziegler Road
  Fax: (970) 288-6580              |  Fort Collins, CO 80525-9790

RE: [Modules] Relative path in MODULEPATH

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

Ric...@se... (Ric...@se...) wrote:

> I am looking into using modules as a project specific
> environment controller.  The project is stored in CVS
> with a project specific modulefile stored in the
> project_root/config directory.  This project specific
> modulefile sets up some project specific environment
> variables, adds a project specific bin directory, and
> does a bunch of non-project specific module loads to
> setup the version of the tools for this project.
> Some of the project specific variables need to be set
> to point to files in the user's working directory and
> can't be set using a relative path.  Since the
> modulefile path is specific to each user's working
> directory (checked out with CVS) the path to the
> modulefile must be added for each user individually
> or a relative path could be used and the user would
> have to be in the root of his own project working
> area in order to run the module load for this project.

Hello Rick,

Mark's suggestion #2 is what I would recommend as
well.  We use that technique for project-specific
dirs on a per-user workspace basis as well as user
modulefile directories using "if {[file exists xxx]}"
in the modulefile.

The fly in the ointment is management of the users'
workspace directory; if you populate a workspace
that uses a non-default name, then the user must
set his/her env var pointing to that workspace on
the fly, outside of modules' control.  Then the
project modulefile needs to be reloaded in each
shell instance.  Messy, but I don't know of a
reasonable alternative that isn't messier or overly
complex.

Usually it's not a problem, though; users who need
to have multiple workspaces can generally handle the
management tasks associated with them.  Modules still
makes this more pleasant than the alternatives, in
my experience.

Regards,

- Leo

Re: [Modules] Relative path in MODULEPATH

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

This isn't the cleanest way, but it was a historical result of a different
configuration tool. We have the following in user's .login:

setenv PROJECT $HOME/my/project/area/diamond
module use $PROJECT/modulefiles
module load diamond/1.0




The alternative is to make a global module available called "projects" in the
default $MODULEFILES path, which sets up the same thing. The user just does
this is their .login:

 module load projects/diamond

And the files look like:

/usr/modules/projects/diamond: --------- (not CVS)
module use $HOME/my/project/area/diamond/modulefiles
module load diamond/1.0


$HOME/my/project/area/diamond/modulefiles/diamond/1.0:------------- (CVS)
module load foo/1.2
module load bar/5.4




-Mark




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

On Mon, 15 Sep 2003 Ric...@se... wrote:

> I am looking into using modules as a project specific environment
> controller.
> The project is stored in CVS with a project specific modulefile stored in
> the project_root/config directory.
> This project specific modulefile sets up some project specific environment
> variables, adds a project specific bin directory, and does a bunch of
> non-project specific module loads to setup the version of the tools for
> this project.
> Some of the project specific variables need to be set to point to files in
> the user's working directory and can't be set using a relative path.
> Since the modulefile path is specific to each user's working directory
> (checked out with CVS) the path to the modulefile must be added for each
> user individually or a relative path could be used and the user would have
> to be in the root of his own project working area in order to run the
> module load for this project.
>
> I used the following setup to get this to work:
> 1) Added config as a relative path in the MODULEPATH variable.
>       Can use "module use" to do this if you were in the project_root
> directory
> 2) Do "module avail" to see the evironments available
>       When in the project_root directory, the project specific modulefiles
> are listed
> 3) Do "module load project_env" to load the project specific environment
>
> The issues that I have found using this model are:
> 1) My version of modulecmd (3.1.6) core dumps if I don't rename the CVS
> directory under the config directory.
> 2) Doing a module unload/purge when I am not in the project_root directory
> fails.
>
> Is there a better way to solve these problems but still allow the
> modulefile to be located with the project database?
>
> Rick
>
>
>
>
> -------------------------------------------------------
> 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
>

[Modules] Relative path in MODULEPATH

[<Ric...@se...>]

I am looking into using modules as a project specific environment
controller.
The project is stored in CVS with a project specific modulefile stored in
the project_root/config directory.
This project specific modulefile sets up some project specific environment
variables, adds a project specific bin directory, and does a bunch of
non-project specific module loads to setup the version of the tools for
this project.
Some of the project specific variables need to be set to point to files in
the user's working directory and can't be set using a relative path.
Since the modulefile path is specific to each user's working directory
(checked out with CVS) the path to the modulefile must be added for each
user individually or a relative path could be used and the user would have
to be in the root of his own project working area in order to run the
module load for this project.

I used the following setup to get this to work:
1) Added config as a relative path in the MODULEPATH variable.
      Can use "module use" to do this if you were in the project_root
directory
2) Do "module avail" to see the evironments available
      When in the project_root directory, the project specific modulefiles
are listed
3) Do "module load project_env" to load the project specific environment

The issues that I have found using this model are:
1) My version of modulecmd (3.1.6) core dumps if I don't rename the CVS
directory under the config directory.
2) Doing a module unload/purge when I am not in the project_root directory
fails.

Is there a better way to solve these problems but still allow the
modulefile to be located with the project database?

Rick

Re: [Modules] LM_LICENSE_FILE/VENDOR_LICENSE_FILE

[<m.a...@co...>]

Thanks again Mark.

That is exactly what we need.

We have about 15 port@node specifications in our LM_LICENSE_FILE
which causes us to require setting SNPSLMD_LICENSE_FILE for only
the Synopsys specific tools - without it we have trouble checking
out licenses...

/Ed
> We set up our tool installations so that the path is well structured, ie.
> something like
> 
> /foo/bar/tool/$os/$version/bin
> 
> and we have just one module file for all versions of the tool, ie
> 
> ---------------------------------------------------
> set version [file tail [module-info name]]
> module-whatis "Synthesis tools, $version"
> 
> set    SYNOPSYS /mips/tools/synopsys/$version
> setenv SYNOPSYS $SYNOPSYS
> 
> append-path SNPSLMD_LICENSE_FILE 1726@mipscs1
> 
> set OS [uname sysname]
> if {$OS == "Linux"} {
>     prepend-path PATH $SYNOPSYS/linux/syn/bin
> } elseif {$OS == "SunOS"} {
>     prepend-path PATH $SYNOPSYS/sparcOS5/syn/bin
> }
> prepend-path MANPATH $SYNOPSYS/doc/syn/man
> prepend-path MANPATH $SYNOPSYS/doc/snps_tcl/man
> # prepend-path MANPATH $SYNOPSYS/doc/pt/man
> conflict synopsys
> ---------------------------------------------------
> 
> this file is saved in ".base" so it is hidden from the module command, and then
> we make a new sym link for each new rev of the software. Sometimes we have to
> branch off into another .base2 file, etc, if the installation rules have
> changed (ie a new env var or path setting).
> 
> mipscs10,AC3> ls -l /mips/tools/freeware/modulefiles/synopsys
> drwxr-xr-x   2 caddood  mips          512 Aug 27 16:17 ./
> drwxr-xr-x 115 caddood  mips         2560 Aug 26 15:09 ../
> -rw-r--r--   1 caddood  mips          811 Jan  7  2003 .base
> -rw-r--r--   1 caddood  mips          948 Aug 27 16:16 .base.temp.2003
> -rw-r--r--   1 caddood  mips          951 May 23 11:16 .base2
> -rw-r--r--   1 caddood  mips           41 Aug 14  2000 .version
> lrwxrwxrwx   1 caddood  mips            5 Jan  4  2001 1999.10 -> .base
> lrwxrwxrwx   1 caddood  mips            5 Jan  4  2001 2000.05 -> .base
> lrwxrwxrwx   1 caddood  mips            5 Feb 12  2001 2000.11 -> .base
> lrwxrwxrwx   1 caddood  mips            5 Jun 25  2001 2000.11-SP2 -> .base
> lrwxrwxrwx   1 caddood  mips            5 Sep 10  2001 2001.06 -> .base
> lrwxrwxrwx   1 caddood  mips            5 Oct 16  2001 2001.08-1 -> .base
> lrwxrwxrwx   1 caddood  mips            5 Apr  1  2002 2001.08-PP1-1 -> .base
> lrwxrwxrwx   1 caddood  mips            5 Mar 25  2002 2001.08-SP2 -> .base
> lrwxrwxrwx   1 caddood  mips            5 Dec 13  2001 2001.08-beta -> .base
> lrwxrwxrwx   1 caddood  mips            5 Aug 15  2002 2002.03-SP1 -> .base
> lrwxrwxrwx   1 caddood  mips            5 Jul  1  2002 2002.05 -> .base
> lrwxrwxrwx   1 caddood  mips            5 Sep 12  2002 2002.05-SP1-E1 -> .base
> lrwxrwxrwx   1 caddood  mips            6 May 23 11:18 2002.05-SP2 -> .base2
> lrwxrwxrwx   1 caddood  mips            5 Feb 22  2002 2002.05-beta -> .base
> lrwxrwxrwx   1 caddood  mips            5 Mar 20  2002 2002.05-beta2 -> .base
> lrwxrwxrwx   1 caddood  mips           15 Aug 27 16:17 2003.03 ->
> .base.temp.2003
> lrwxrwxrwx   1 caddood  mips           15 Aug 27 16:17 2003.06 ->
> .base.temp.2003
> 
> 
> -Mark
> 
> Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
> 
> On Tue, 9 Sep 2003 m.a...@co... wrote:
> 
> > Thanks Mark.
> >
> > Somehow the simple solution was obscured by the
> > confusing implementation sitting in front of me.
> >
> > Another quick question.  We might have 5 or 6
> > versions of tool A or too B installed.  The only
> > thing which changes from version to version is
> > the installation path however we have N files to
> > edit to modify the license info.  What is the
> > proper way of #include-ing the license info so
> > it can be centralized?
> >
> > I've recently become owner of our module files
> > after a 2+ year hiatus.
> >
> > /Ed
> > > We do exactly the same thing. I'm not sure what your problem is though, it
> > > seems straightforward.
> > >
> > > a/abc : prepend-path VENDORA_LICENSE_FILE /vendor/a/lic/path
> > > a/def : prepend-path VENDORA_LICENSE_FILE /vendor/a/lic/path
> > > c/xyz : prepend-path LM_LICENSE_FILE /vendor/c/lic/path
> > > d/qrs : prepend-path LM_LICENSE_FILE /vendor/d/lic/path
> > >
> > > ?
> > >
> > >
> > >
> > > -Mark
> > >
> > >
> > > Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> > > MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
> > >
> > > On Tue, 9 Sep 2003 m.a...@co... wrote:
> > >
> > > > Hi,
> > > >
> > > > We have multiple tools by multiple vendors.
> > > > Our LM_LICENSE_FILE string required by all tools
> > > > is too large for some vendors.  They supply a
> > > > vendor specific string, e.g. VENDORA_LICENSE_FILE.
> > > >
> > > > The problem is when the vendor has two tools which
> > > > we require, e.g. vendor_a/tool_abc and vendor_a/tool_def
> > > > and we have other vendor's tools, vendor_c/tool_xyz
> > > > and vendor_d/tool_qrs.
> > > >
> > > > I do not want each tool's contribution to LM_LICENSE_FILE
> > > > to show up in VENDORA_LICENSE_FILE only the contribution
> > > > from tool_abc and tool_def.
> > > >
> > > > Should I maintain environment variables for tool_abc
> > > > and tool_def and use those to set VENDORA_LICENSE_FILE?
> > > >
> > > > I hope this is clear...
> > > >
> > > > Thanks,
> > > > /Ed
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > 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
> > > >
> >

Re: [Modules] LM_LICENSE_FILE/VENDOR_LICENSE_FILE

[Nils S. <sm...@pd...>]

Also if you are you are using many different applications that all use
the network based license scheme in FlexLM you might consider having
a dedicated license server and concatenating the different licenses 
into one licenses file on the server. This will most likely shorten 
your license path down to a small number of entries, such as:

LM_LICENSE_FILE=po...@fl...:po...@fl...

In this case the user applications do not have to have the license file
in their file system at all. They will call out to the license server
instead.

/Nils

Re: [Modules] LM_LICENSE_FILE/VENDOR_LICENSE_FILE

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

We set up our tool installations so that the path is well structured, ie.
something like

/foo/bar/tool/$os/$version/bin

and we have just one module file for all versions of the tool, ie

---------------------------------------------------
set version [file tail [module-info name]]
module-whatis "Synthesis tools, $version"

set    SYNOPSYS /mips/tools/synopsys/$version
setenv SYNOPSYS $SYNOPSYS

append-path SNPSLMD_LICENSE_FILE 1726@mipscs1

set OS [uname sysname]
if {$OS == "Linux"} {
    prepend-path PATH $SYNOPSYS/linux/syn/bin
} elseif {$OS == "SunOS"} {
    prepend-path PATH $SYNOPSYS/sparcOS5/syn/bin
}
prepend-path MANPATH $SYNOPSYS/doc/syn/man
prepend-path MANPATH $SYNOPSYS/doc/snps_tcl/man
# prepend-path MANPATH $SYNOPSYS/doc/pt/man
conflict synopsys
---------------------------------------------------

this file is saved in ".base" so it is hidden from the module command, and then
we make a new sym link for each new rev of the software. Sometimes we have to
branch off into another .base2 file, etc, if the installation rules have
changed (ie a new env var or path setting).

mipscs10,AC3> ls -l /mips/tools/freeware/modulefiles/synopsys
drwxr-xr-x   2 caddood  mips          512 Aug 27 16:17 ./
drwxr-xr-x 115 caddood  mips         2560 Aug 26 15:09 ../
-rw-r--r--   1 caddood  mips          811 Jan  7  2003 .base
-rw-r--r--   1 caddood  mips          948 Aug 27 16:16 .base.temp.2003
-rw-r--r--   1 caddood  mips          951 May 23 11:16 .base2
-rw-r--r--   1 caddood  mips           41 Aug 14  2000 .version
lrwxrwxrwx   1 caddood  mips            5 Jan  4  2001 1999.10 -> .base
lrwxrwxrwx   1 caddood  mips            5 Jan  4  2001 2000.05 -> .base
lrwxrwxrwx   1 caddood  mips            5 Feb 12  2001 2000.11 -> .base
lrwxrwxrwx   1 caddood  mips            5 Jun 25  2001 2000.11-SP2 -> .base
lrwxrwxrwx   1 caddood  mips            5 Sep 10  2001 2001.06 -> .base
lrwxrwxrwx   1 caddood  mips            5 Oct 16  2001 2001.08-1 -> .base
lrwxrwxrwx   1 caddood  mips            5 Apr  1  2002 2001.08-PP1-1 -> .base
lrwxrwxrwx   1 caddood  mips            5 Mar 25  2002 2001.08-SP2 -> .base
lrwxrwxrwx   1 caddood  mips            5 Dec 13  2001 2001.08-beta -> .base
lrwxrwxrwx   1 caddood  mips            5 Aug 15  2002 2002.03-SP1 -> .base
lrwxrwxrwx   1 caddood  mips            5 Jul  1  2002 2002.05 -> .base
lrwxrwxrwx   1 caddood  mips            5 Sep 12  2002 2002.05-SP1-E1 -> .base
lrwxrwxrwx   1 caddood  mips            6 May 23 11:18 2002.05-SP2 -> .base2
lrwxrwxrwx   1 caddood  mips            5 Feb 22  2002 2002.05-beta -> .base
lrwxrwxrwx   1 caddood  mips            5 Mar 20  2002 2002.05-beta2 -> .base
lrwxrwxrwx   1 caddood  mips           15 Aug 27 16:17 2003.03 ->
.base.temp.2003
lrwxrwxrwx   1 caddood  mips           15 Aug 27 16:17 2003.06 ->
.base.temp.2003


-Mark

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

On Tue, 9 Sep 2003 m.a...@co... wrote:

> Thanks Mark.
>
> Somehow the simple solution was obscured by the
> confusing implementation sitting in front of me.
>
> Another quick question.  We might have 5 or 6
> versions of tool A or too B installed.  The only
> thing which changes from version to version is
> the installation path however we have N files to
> edit to modify the license info.  What is the
> proper way of #include-ing the license info so
> it can be centralized?
>
> I've recently become owner of our module files
> after a 2+ year hiatus.
>
> /Ed
> > We do exactly the same thing. I'm not sure what your problem is though, it
> > seems straightforward.
> >
> > a/abc : prepend-path VENDORA_LICENSE_FILE /vendor/a/lic/path
> > a/def : prepend-path VENDORA_LICENSE_FILE /vendor/a/lic/path
> > c/xyz : prepend-path LM_LICENSE_FILE /vendor/c/lic/path
> > d/qrs : prepend-path LM_LICENSE_FILE /vendor/d/lic/path
> >
> > ?
> >
> >
> >
> > -Mark
> >
> >
> > Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> > MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
> >
> > On Tue, 9 Sep 2003 m.a...@co... wrote:
> >
> > > Hi,
> > >
> > > We have multiple tools by multiple vendors.
> > > Our LM_LICENSE_FILE string required by all tools
> > > is too large for some vendors.  They supply a
> > > vendor specific string, e.g. VENDORA_LICENSE_FILE.
> > >
> > > The problem is when the vendor has two tools which
> > > we require, e.g. vendor_a/tool_abc and vendor_a/tool_def
> > > and we have other vendor's tools, vendor_c/tool_xyz
> > > and vendor_d/tool_qrs.
> > >
> > > I do not want each tool's contribution to LM_LICENSE_FILE
> > > to show up in VENDORA_LICENSE_FILE only the contribution
> > > from tool_abc and tool_def.
> > >
> > > Should I maintain environment variables for tool_abc
> > > and tool_def and use those to set VENDORA_LICENSE_FILE?
> > >
> > > I hope this is clear...
> > >
> > > Thanks,
> > > /Ed
> > >
> > >
> > > -------------------------------------------------------
> > > 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
> > >
>

Re: [Modules] LM_LICENSE_FILE/VENDOR_LICENSE_FILE

[<m.a...@co...>]

Thanks Mark.

Somehow the simple solution was obscured by the
confusing implementation sitting in front of me.

Another quick question.  We might have 5 or 6
versions of tool A or too B installed.  The only
thing which changes from version to version is
the installation path however we have N files to
edit to modify the license info.  What is the
proper way of #include-ing the license info so
it can be centralized?

I've recently become owner of our module files
after a 2+ year hiatus.

/Ed
> We do exactly the same thing. I'm not sure what your problem is though, it
> seems straightforward.
> 
> a/abc : prepend-path VENDORA_LICENSE_FILE /vendor/a/lic/path
> a/def : prepend-path VENDORA_LICENSE_FILE /vendor/a/lic/path
> c/xyz : prepend-path LM_LICENSE_FILE /vendor/c/lic/path
> d/qrs : prepend-path LM_LICENSE_FILE /vendor/d/lic/path
> 
> ?
> 
> 
> 
> -Mark
> 
> 
> Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
> 
> On Tue, 9 Sep 2003 m.a...@co... wrote:
> 
> > Hi,
> >
> > We have multiple tools by multiple vendors.
> > Our LM_LICENSE_FILE string required by all tools
> > is too large for some vendors.  They supply a
> > vendor specific string, e.g. VENDORA_LICENSE_FILE.
> >
> > The problem is when the vendor has two tools which
> > we require, e.g. vendor_a/tool_abc and vendor_a/tool_def
> > and we have other vendor's tools, vendor_c/tool_xyz
> > and vendor_d/tool_qrs.
> >
> > I do not want each tool's contribution to LM_LICENSE_FILE
> > to show up in VENDORA_LICENSE_FILE only the contribution
> > from tool_abc and tool_def.
> >
> > Should I maintain environment variables for tool_abc
> > and tool_def and use those to set VENDORA_LICENSE_FILE?
> >
> > I hope this is clear...
> >
> > Thanks,
> > /Ed
> >
> >
> > -------------------------------------------------------
> > 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
> >