(This is the page that used to be at std_env and described the addon re-design.)

std_env is the package that provides all the "standard" portions of a system environment for tools to run in. Historically, "standard" has been defined as "needed to build vesta." I'd like to make std_env more general. After some discussions with KenSchalk about this, here's my suggestion.

Currently, running std_env()/env_build() gets you everything that's in std_env. If you need to add additional components, you need to know the exact name of the OS package that provides them, and this name can differ from os to os (for example, "libc6" on debian vs. "glibc" on redhat).

I'd like to strip std_env down to just return the basic run time libraries, and then have a series of "add-ons" - additional models that live in the same package as std_env and can be imported by other models and added directly into std_env on demand. The add-ons would be everything from tools (gcc, lex, yacc, perl, etc.) to libraries (vesta_umb, libbzip2, etc). These add-on models would have to support some sort of overrides at least as flexible as std_env()/env_build() currently does. The add-on models would know the proper name for the import for the component they provide into that particular std_env. They should probably also exist, but print an error message, for std_env platforms that don't support that component.

Supporting overrides for the individual components means some method for passing parameters to them. That could be done the same way we do it for std_env (have the model return a function which is then called with arguments): 

   1 perl_ovs = [ ... ];
   2 . ++= perl()/env_build(perl_ovs);

Or we could have the caller place something in dot before calling the model: 

   1 perl_ovs = [ ... ];
   2 . ++= perl(. + [ perl_ovs ]);

We might not even need to pass the current value of dot into the add-on model. Bridges that need to compile tools from source should delay such compilation until the tool needs to be invoked. (The lim bridge used to compile at env_build time, but I changed that a long time ago.) 

   1 perl_ovs = [ ... ];
   2 . ++= perl(perl_ovs);

Perhaps one reason to pass the current dot in is to allow the add-in to detect if any of the other add-ons it needs are present already. For example, any tool or library built from source under Vesta needs the appropriate compilation tools/bridges in dot. Should the caller be required to know which things to add in first? 

   1 . ++= c_addon();
   2 . ++= cxx_addon();
   3 . ++= gclib_addon();
   4 . ++= basicslibs_addon();
   5 . ++= zlib_addon();
   6 . ++= vestalibs_addon();

Or just call the add-in model and have it pull in the others? 

   1 . ++= vestalibs_addon();

The latter seems like a big simplification for user models. However, then we probably have to pass overrides down into any dependent add-on model.

-- KenSchalk

ScottVenier has done an initial implementation of this idea:

/vesta/beta.vestasys.org/platforms/linux/redhat/i386/std_env/1

He's also made a Vesta release using this (though it's not quite right, as currently every progrm is being linked with the garbage collector):

/vesta/beta.vestasys.org/vesta/release/2