What we have now

Linux/Mac

RM builds create files _setup.sh, _setup.csh which just set certain environment variables and they create wrapper scripts for each executable. The wrapper scripts have the same name as the executable (e.g., test_xmlBase) but are to be run by sh.

For these scripts to work properly, caller must have already established values for GLAST_EXT and for INST_DIR.

Normal usage for wrapper scripts is to just run them; executable runs in a separate process and parent process is untouched.  Normal usage for _setup.csh or _setup.sh is to source it, modifying the environment of the original (and only) process

Windows

RM builds create a file _setup.js which just sets certain environment variables and they create wrapper scripts with names like test_xmlBase.js.

For these scripts to work properly, caller must have already established the value for GLAST_EXT.  (INST_DIR is deduced from location of _setup.js or wrapper script, located two subdirectories down.)

Running a js script first creates a new dos window which inherits its environment from the parent, then executes the code in the scriipt to modify the environment of the new dos process.

What gets established by setup

For Linux/Mac: LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, PATH, PYTHONPATH, PFILES, ROOTSYS

For Windows: PATH, PYTHONPATH, PFILES, ROOTSYS

Of these, PFILES is by far the most complicated, involving quite a bit of logic.  The others are straightforward. However the PFILES computation is always the same except for two or three inputs:

  1. Home directory
  2. INST_DIR
  3. BASE_DIR if different from INST_DIR

If not for PFILES, Windows setup could be done just as well by a .bat file. (GR does not currently involve PFILES and most likely never will.)

Usage

Read-only

The intent is that none of these supplied scripts be modified by users. Users needing additional custom set-up should embody that in their own scripts (which might invoke the supplied _setup as one step).

Wrapper scripts versus _setup

Wrapper scripts are convenient when they suffice, but

  • it's inefficient to keep creating processes for each program execution
  • they're less flexible.  In particular, it's impossible to do any additional custom set-up after the SCons setup but before running the executable

Hence we could get along with the general _setup and no wrapper scripts, but not the other way around.

What's missing or broken

Current implementation is (perhaps only barely) adequate for Linux/Mac as far as I know.  But on Windows

  1. Environment is not getting propagated properly when Studio is started up from GoGui (applies only to VS 2008 since SCons only creates project and solutions files for that compiler) 
  2. On systems with more than one compiler installed, the various setup scripts do not know anything about the environment in effect when the script was created except for certain environment variables (PATH, PYTHONPATH, etc).  In particular, values for environment variables LIB and (VS 2008 only) LIBPATH are not recovered. The environment for one or another compiler can be established by running a (Microsoft-supplied) file, but exactly where the file is and what it's called depends on compiler version and also may depend on the particular installation if the user chose a non-standard install location.

2. above may doom any scheme in which the set-up file is generated once and for all by RM or, at the very least, more inputs besides GLAST_EXT and INST_DIR will be required if the set-up file is to work on remote machines.

For discussion

  1. pfiles - under what circumstances must the environment variable PFILES be set in the standard fashion?  Is it possible to extract this task into a separate script which could be treated as source (e.g., stored in ScienceTools-scons/containerSettings), to be invoked by _setup when needed?
  2. what to do about set-up on machines other than the one where the _setup file was built.
  • No labels