CVS: sidai/vwrapper toolenv,1.10,1.11

[Will P. <pa...@us...>]

Update of /cvsroot/ark/sidai/vwrapper
In directory sc8-pr-cvs11.sourceforge.net:/tmp/cvs-serv628

Modified Files:
	toolenv 
Log Message:
final version before rewrite

Index: toolenv
===================================================================
RCS file: /cvsroot/ark/sidai/vwrapper/toolenv,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -r1.10 -r1.11
*** toolenv	17 May 2006 10:06:57 -0000	1.10
--- toolenv	26 Nov 2007 11:07:28 -0000	1.11
***************
*** 39,42 ****
--- 39,44 ----
  ################################################################
  
+ # notes by GordonA at the end
+ 
  __version__ = "$Revision$"[11:-2]
  
***************
*** 451,452 ****
--- 453,560 ----
  
  # the end
+ 
+ # further notes
+  
+ # From: "Gordon Allan"
+ # Subject: Re: toolenv proposal
+ # To: "Will Partain"
+ # Date: Fri, 16 Apr 2004 09:19:25 +0100
+ 
+ # >   env-spec: a comma-separated list of env-spec-items
+ # > 
+ # >   env-spec-item:
+ # >     Typically an Arusha package name, which has the
+ # >     meaning of "go get environment-manipulating commands from a
+ # >     special file that you know where it is".
+ # > 
+ # >     If the first character is ! , then the rest of the item is taken
+ # >     to be a literal environment-manipulating command itself.
+ # > 
+ # > The "environment-manipulating" commands comprise a little language,
+ # > and are executed in order, to produce the final environment that will
+ # > be used.  The commands are: 
+ # > 
+ # >  FOO=a/b/c   set FOO exactly to a/b/c; duplicates are a problem
+ # >  FOO+=a:b    prepend a:b to an existing FOO setting
+ # >  FOO=+a:b    append  a:b to an existing FOO setting
+ # >  FOO=?a/b    set FOO to a/b if it is not set already
+ # >  FOO-        remove FOO from the environment
+ # >  comments (#-to-end-of-line) and blank lines are OK, too.
+ # >  __clean__   throw away the environment and start fresh
+ # >  __file__ filename  read commands from filename
+ 
+ # All looks good..
+ 
+ # e.g.
+ 
+ # > COMPILE_ENV="!__clean__,verisity-specman"
+ # > COMPILE_ENV="$COMPILE_ENV,!SPECMAN_GCC=/my/strange/gcc"
+ # > toolenv $COMPILE_ENV sn_compile.sh foo.e bar.e -exe out
+ # > ...
+ # > RUN_ENV="!__clean__,verisity-specman,synopsys-vcs"
+ # > RUN_ENV="$RUN_ENV,!VCS_GUBBINS=/foo/gub,!LD_LIBRARY_PATH+=/foo/barf"
+ # > toolenv $RUN_ENV ./simv arg arg2
+ 
+ # [1] But there is a problem in the logic with versioning, I think...
+ 
+ # Example:
+ 
+ # At build/compile-time, I use a tool 'vcs' or 'specman' or 'sn_compile.sh' and with
+ # the wrapper stuff in place I know to add a --use-version=4.2.1 or whatever.
+ 
+ # But at runtime if I invoke:
+ #        "toolenv verisity-specman,synopsys-vcs ./my_exe"
+ # then what version number of 'verisity-specman' is used, what version of 'synopsys-vcs'
+ 
+ # I'd expect (somehow) to be able to say:
+ 
+ # > VCS_VERSION=7.0.1
+ # > SPECMAN_VERSION=4.2.1
+ # > ...
+ # > sn_compile.sh --use-version=$SPECMAN_VERSION foo.e bar.e -exe out
+ # > vcs --use-version=$VCS_VERSION my.v test.v specman.v other.libs
+ # > ...
+ # > RUN_ENV="!__clean__,verisity-specman-$SPECMAN_VERSION,synopsys-vcs-$VCS_VERSION"
+ # > RUN_ENV="$RUN_ENV,!VCS_GUBBINS=/foo/gub,!LD_LIBRARY_PATH+=/foo/barf"
+ # > toolenv $RUN_ENV ./simv arg arg2
+ 
+ # Can I? That way or another way?
+ 
+ # Maybe there is no problem though - when I type 'specman --show-versions' it seems
+ # to return info that makes me think you have thought this through. are there particular
+ # dependencies between packages coming into play here that the user would need to
+ # know about?
+ 
+ # [2] I like the '!' syntax - it is 'in yer face' enough that you can see some overriding is
+ # going on. I bet folks will forget the syntax quickly though - keep it accessible.
+ 
+ # [3] The only way to introduce a 'guaranteed clean package env plus override' at *compile*
+ # time is to use toolenv for the compile also. e.g. instead of :
+ 
+ # > SPECMAN_GUBBINS=mode-2
+ # > sn_compile.sh --use-version=$SPECMAN_VERSION foo.e bar.e -exe out
+ 
+ # ...you would want:
+ 
+ # > toolenv "!__clean__,verisity-specman[version?],!SPECMAN_GUBBINS=mode2" sn_compile.sh foo.e bar.e -exe out
+ 
+ # i.e. the versioning thing needs moved probably from the traditional tool wrapper to the toolenv way.
+ 
+ # Behind the scenes I guess this is calling toolenv twice :-(
+ 
+ # So.. instead you could have the toolenv string passed from the wrapped compiler with a new option syntax, e.g.:
+ # > sn_compile.sh --use-env="!__clean__,verisity-specman[version?],!SPECMAN_GUBBINS=mode2" foo.e bar.e -exe out
+ 
+ # Hmm. but there is still stuff there that the user didnt really want to know about, i..e the "verisity-specman" package
+ # which arusha already knows is something that needs setup whenever 'sn_compile.sh' is called.
+ 
+ # ..but I'd still like a '__clean__' before the 'implicit package' and a '!OVERRIDE=x' after it.
+ 
+ # So maybe you could have a --use-env option and add a '__default__' flag which means 'get the package[s] for this
+ # wrapped executable *now* in the comma-separated sequence.'
+ 
+ # Trying hard to keep it simple.... maybe calling toolenv twice is OK.
+ 
+ # Cheers,
+ 
+ # --gordon