• std_env

What is std_env?

std_env is the name of a package that provides a "standard build environment" which other SDL models can use to perform builds.

There are several different std_env packages which provide build environments for different target platforms. For example:

Each of these gathers together the neccessary pieces to provide the same interface for client models which want to perform some build activity like compiling a collection of C/C++ source files into an executable binary.

What makes up std_env?

Each std_env is several Vesta SDL files which gather together several different things:

• The files needed to compile such as compiler binaries, standard libraries, etc. (These are, of course, specific to the platform on which the tools will run.) The files are normally grouped into OS components (or just components) which represent some subset of the files provided by the OS vendor.

• Collections of SDL code which provide an abstract interface for performing different build activites. These are known as bridges.

• Libraries for use by client models. Most often these are C/C++ libraries such a standard libraries like libc and libpthread or libraires built from C/C++ source under Vesta control.

Of course this isn't necessarily everything that std_env provides. Different languages or tools might need additional functions or data structures stored in the special variable ".". (For example, the original std_env also included a Modula-3 bridge and a collection of Modula-3 libraires.)

OS Components

On a system that uses the RedHat package manager, an OS component would be the contents of one RPM. On a system using the Debian package manager, an OS component would be the contents of one .deb. On a Tru64 system, an OS component would be the files which make up one Tru64 subset.

Here are the OS components for the gcc compiler for seveal different systems:

Organizing the platform-specific files in this way makes it easier to upgrade the versions of components over time and to create new std_envs. Also, keeping the platform-specific files separate from the libraries of SDL code (aka bridges) makes it easier to re-use the latter across multiple different platforms.

Bridges

In Vesta parlance, a bridge is a library of one or more SDL functions which know how to perform some abstract build task. They take care of the details of setting up the filesystem and command line, running tools (with the _run_tool primitive function), and gathering up the result files. They bridge the gap between the high-level operations users are interested and the details of carrying those operations.

Here are a few of the standard bridges for common tasks:

Libraries

The C/C++ libraries provided by a std_env are SDL objects which can be passed to functions from the c_like bridge (usually ./C/program or ./Cxx/program).

Here are a few examples you might find in SDL models:

Add-ons: Choosing what's in your build environment

Originally, std_env always included a fixed set of OS components, bridges, and libraries. This meant that if your build needed something else, you would have to add it to the special variable "." after std_env had prepared the basic build environment for you. (For an example of this, probably the motivating example for the implementation of std_env add-ons, see /vesta/beta.vestasys.org/vesta/extras/swig/10/linux_i386.main.ves.)

Recently this changed with the introduction of std_env add-ons. This allows you to specify exactly what your build needs in its build environment. You get just what you asked for, nothing more, nothing less. This makes it easier to mix and match build environment elements, at the cost of slightly more code in the client top-level model.

For example, the Vesta release build asks for three add-ons in its build environment:

• C++ compilation and standard libraries
• The Vesta C++ libraries
• The mtex documentation processor

This is done by importing one model per add-on and passing a binding of add-ons as the first argument to the env_build function:

   1 from /vesta/vestasys.org/platforms/linux/debian/i386 import
   2   // std_env itself is very minimal
   3   std_env/2;
   4   // We need these three add-ons to build Vesta
   5   addons = [
   6     cxx = std_env/2/cxx.ves,
   7     libvesta = std_env/2/libvesta.ves,
   8     mtex = std_env/2/mtex.ves,
   9   ];
  10 
  11 {
  12   // Prepare the build environment.
  13   pkg_ovs = [];
  14   . = std_env()/env_build(addons, pkg_ovs);
  15 
  16   // ...
  17 }

More Detail

If you'd like to know more about std_env, there's some greater technical detail in some sub-pages:

• /MakeNewOsComponent - How to import an OS component for use with std_env

• /MakeNewAddOn - How to make your own add-on for std_env

• /MakeNewStdEnv - How to make your own std_env for a new platform

• /AddonSpec - Exactly what does an addon return?

• /OsComponentSpec - Exactly what's in an OS component?

• /AddonProposal - The original page proposing add-ons