How to make a new std_env

Start from an existing similar std_env

The easiest way to create a new build environment is to start with an existing one and modify it. There are several different ones that you can choose from to start from:

Debian sarge Linux for i386


RedHat Linux 7 for i386


Debian sarge Linux for PowerPC


Tru64 V4.0 for Alpha


Each of these has several SDL model files:

Some of these have a lot of platform-specific pieces.

Others are largely platform-independent.

Find the OS components you need to import

Most of what makes a particular build environment specific to a given target platform is the set of files used to populate the encapsulated filesystems. When importing those platform-specific files into Vesta, we split them into Vesta packages based on the natural OS packaging mechanism (e.g. RPM or the Debian packaging system on many Linux systems). See std_env/OsComponentSpec for more on what's in an OS component.

Creating a new build environment by modifying an old one is largely a matter of replacing the OS components with new ones and correcting the SDL code to work correctly with the new OS components.

Make a "Shopping List" from the Old std_env

One way to start is to look through the model imports of the SDL models in the build environment you are starting from. It should be pretty easy to find the ones which are OS components, as such models are conventionally stored below a directory named "components". Here's an example of how you might go about making such a list:

% cd /vesta/
% for f in *.ves; do echo $f; vimports -depth 1 $f | grep /components/; done
| /vesta/
| /vesta/
| /vesta/
| /vesta/
| /vesta/
| /vesta/
| /vesta/
| /vesta/
| /vesta/
| /vesta/
| /vesta/
| /vesta/
| /vesta/
| /vesta/
| /vesta/
| /vesta/

From this we can see the set of OS component names used in this (Debian sarge) std_env:

Based on this list of OS component names, we can look for ones with the same names in the other OS. Of course this method works best when the old and new target systems are very similar (e.g. different versions of the same vendor's Linux distribution).

Make a "Shopping List" Based on Filesystem Paths

Another method would be to actually look at the tool command names and other filesystem paths being used.

There's a general practice of making bridge code such as [ the lex bridge] or [ the C/C++ compilation bridge] accept command names as arguments rather than having them hard-coded. By reading the SDL code which specializes the different bridges for a particular platform, you can find specific file paths to be used when running the tools.

For system C/C++ libraries, there is SDL code to package up the .a/.so files and the associated headers in a way that the c_like bridge can use them. (You can find such references in c.ves and cxx.ves among others.)

Other pieces of the std_env SDL code may refer to other filesystem paths.

Of course these paths may also be different from one platform to another, but the path names can help point you in the right direction. If you've found the corresponding file on your target system, there's often a method to query the OS packaging system for which OS component package contains a given file:

RPM systems

rpm -qf /path/to/some/file

Debian systems

dpkg -S /path/to/some/file

Digital/Compaq/HP Tru64 UNIX

grep /path/to/some/file /usr/.smdb./*.inv

Inspect the Dependencies/Contents of Target Components

In some cases, you may need to resort to examining in detail the component packages of the target system. (For example, if you're creating a build environment for a system which you don't have a running copy of.)

Many packaging systems provide some way to inspect the contents of an un-installed package file:

Many packaging systems also provide a way to examine the inter-package dependencies of an un-installed package file:

In many cases you don't actually need to import all the dependencies to get a working build environment, but they can be another useful clue.

There may be other information you can get from the packaging system that will be helpful. You may want to familiarize yourself with the packaging system.

Import the OS Components

Now that you have your list of OS components, import them into Vesta as sources.

See std_env/MakeNewOsComponent for information on how to do this.

Update std_env Models

Now that you have immutable source versions containing the platform-specific files for your target build environment, change the imports of your std_env SDL files to refer to them.

After you've done that you will want to look through the models for any calls to ./build_root or other references to the OS component names and update them if necessary.

You'll also want to check any references to specific file/directory paths extracted from the OS components.

Test, Correct, Repeat

At this point, you should be able to start testing your build environment. Some of the kinds of problems you may run into:


Here are a couple examples of the creation of new build environments: