Contents
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:
A base model (build.ves) which provides the core of the build environment with no add-ons
A collection of add-on models (see std_env/AddonSpec) for various build environment features:
C compilation (c.ves)
C++ compilation (cxx.ves)
Lexical analyzer generation (lex.ves)
On some platforms this uses flex and on others it uses a vendor supplied lex
Parser generation (yacc.ves)
On Linux we've used byacc for this, though it might be possible to replace it with bison
The basics libraries (libbasics.ves)
The Boehm garbage collector library (libgc.ves)
The Vesta libraries (libvesta.ves)
The zlib compression library (libz.ves)
The mtex documentation processing package which we use for the Vesta man pages (mtex.ves)
The lim interpreted language which mtex is implemented in (lim.ves)
Some of these have a lot of platform-specific pieces.
build.ves will include references to the OS components for basic run-time libraries.
Models for compilers and other build tools (c.ves, cxx.ves, lex.ves, yacc.ves) include references to the OS components containing the binaries for those tools.
Others are largely platform-independent.
lim.ves simply refers to the lim bridge and the other add-ons needed to compile the lim interpreter from source (c.ves, lex.ves, and yacc.ves)
mtex.ves simply refers to the mtex bridge and the lim.ves add-on
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/vestasys.org/platforms/linux/debian/i386/std_env/2 % for f in *.ves; do echo $f; vimports -depth 1 $f | grep /components/; done build.ves | /vesta/vestasys.org/platforms/linux/debian/i386/components/libc6/2.3.2.ds1-22/1/build.ves... | /vesta/vestasys.org/platforms/linux/debian/i386/components/libstdc++5/1:3.3.5-13/1/build.ves... | /vesta/vestasys.org/platforms/linux/debian/i386/components/libgcc1/1:3.4.3-13/1/build.ves... c.ves | /vesta/vestasys.org/platforms/linux/debian/i386/components/binutils/2.15-6/1/build.ves... | /vesta/vestasys.org/platforms/linux/debian/i386/components/cpp/4:3.3.5-3/1/build.ves... | /vesta/vestasys.org/platforms/linux/debian/i386/components/cpp-3.3/1:3.3.5-13/1/build.ves... | /vesta/vestasys.org/platforms/linux/debian/i386/components/gcc/4:3.3.5-3/1/build.ves... | /vesta/vestasys.org/platforms/linux/debian/i386/components/gcc-3.3/1:3.3.5-13/1/build.ves... | /vesta/vestasys.org/platforms/linux/debian/i386/components/libc6-dev/2.3.2.ds1-22/1/build.ves... | /vesta/vestasys.org/platforms/linux/debian/i386/components/linux-kernel-headers/2.5.999-test7-bk-17/1/build.ves... cxx.ves | /vesta/vestasys.org/platforms/linux/debian/i386/components/g++/4:3.3.5-3/1/build.ves... | /vesta/vestasys.org/platforms/linux/debian/i386/components/g++-3.3/1:3.3.5-13/1/build.ves... | /vesta/vestasys.org/platforms/linux/debian/i386/components/libstdc++5-3.3-dev/1:3.3.5-13/1/build.ves... family_map.ves lex.ves | /vesta/vestasys.org/platforms/linux/debian/i386/components/flex/2.5.31-31/1/build.ves... | /vesta/vestasys.org/platforms/linux/debian/i386/components/m4/1.4.2-1/1/build.ves... libbasics.ves libgc.ves libvesta.ves libz.ves lim.ves mtex.ves yacc.ves | /vesta/vestasys.org/platforms/linux/debian/i386/components/byacc/1.9.1-1.1/1/build.ves...
From this we can see the set of OS component names used in this (Debian sarge) std_env:
- libc6
- libstdc++5
- libgcc1
- binutils
- cpp
- cpp-3.3
- gcc
- gcc-3.3
- libc6-dev
- linux-kernel-headers
- g++
- g++-3.3
- libstdc++5-3.3-dev
- flex
- m4
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 [http://pub.vestasys.org/cgi-bin/vestaweb?path=/vesta/vestasys.org/bridges/lex the lex bridge] or [http://pub.vestasys.org/cgi-bin/vestaweb?path=/vesta/vestasys.org/bridges/c_like 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:
- RPM
rpm -qlp foo-1.2.3-4.i386.rpm will list the contents of the given RPM file
- Debian
dpkg -c foo_1.2.3-4_i386.deb will list the contents of the given Debian package file
Many packaging systems also provide a way to examine the inter-package dependencies of an un-installed package file:
- RPM
rpm -q --requires -p foo-1.2.3-4.i386.rpm
- Debian
dpkg -f foo_1.2.3-4_i386.deb Depends
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:
- Tool failures due to missing files requiring you to import more OS components (or different OS components, or additional or different pieces of OS components)
- SDL errors due to code trying to access files from OS components which aren't there
- You might need to fix the SDL code to access different paths
- You might need to import more OS components
- Errors in your updated SDL code
Errors in or warnings from the automatically generated SDL models in OS components imported with pkg2vesta.pl (root.ves, build.ves)
Examples
Here are a couple examples of the creation of new build environments: