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:

Debian sarge Linux for i386


RedHat Linux 7 for i386


Debian sarge Linux for PowerPC


Tru64 V4.0 for Alpha


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:

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:

Debian sarge Linux for i386


RedHat Linux 7 for i386


Debian sarge Linux for PowerPC


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.


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:

Compiling C/C++


lex (generates C code for lexical analysis)


yacc (generates C code for parsing)





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:

SDL Expression

Referenced Library


The standard C run-time library


The standard C math library


src/lib.ves in /vesta/vestasys.org/basics/basics


src/lib.ves in /vesta/vestasys.org/vesta/config

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:

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   ];
  11 {
  12   // Prepare the build environment.
  13   pkg_ovs = [];
  14   . = std_env()/env_build(addons, pkg_ovs);
  16   // ...
  17 }

More Detail

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