• TopLevelModelNames

Background

A "top-level model" is the kind given directly to the Vesta builder. Typically these return values such as executable programs or some other result produced through compilers or other tools.

Top-level models normally import the build environment for a particular target platform and then call some other model (passing the build envionment as a parameter theough the special variable "."). This allows the models which describe what to build to be written in a platform-neutral way, and thus be re-used across many platforms.

If you give the builder a directory without specifying a top-level model file name, it will look for the model names specified in the [Evaluator]DefaultMain setting in the Vesta configuration file. Typically this list is set such that the most appropriate model name for the platform where you're running the builder is first, followed by others which may not be as close but might still produce results which will work on your platform.

Old style

When Vesta was first developed, and it ran on just one platform, top-level models were named .main.ves. This is still the default if [Evaluator]DefaultMain is not set, and some people still use this for their top-level models.

New style

When Vesta was being ported to Linux and prepared for public release, it became clear that we would have several top-level models for the different platforms Vesta would run on. We needed a naming convention. We started with:

• os_cpu.main.ves

More recently, it became clear that we would need variants for different operating system versions, so we expanded this to:

• os_cpu_osrev.main.ves

(This is what we use for the Vesta free software project. There's no enforcement of this convention. You can name your top-level models differently if you like.)

OS Strings

The OS strings currently in use by the Vesta free software project are:

These will probably be used in the future:

CPU Strings

The CPU strings currently in use by the Vesta free software project are:

These have been used in the past, but don't tend to get used today:

i686

Intel 80686 and up. (We prefer to build for 386 which is more generic.)

ia32

Another name for i386. (This name doesn't make it clear whether it's for i386 or i686, and it can matter.)

OS Version Strings

The OS version strings currently in use by the Vesta free software project are:

These will probably be used in the future:

"All" models

It's sometimes convenient to have a model which will build for multiple target platforms. These models simply import multiple other top-level models and call all of them (usually with _par_map). These models are sometimes named simply:

• all.main.ves

There are also sometimes models which build for every OS revision for a particula OS/CPU combination (e.g. both Red Hat 7 and Debian sarge for Linux on i386). These models are named:

• all_os_cpu.main.ves

Makefile Export

We have a build environment which generates a make-based source kit (rather than compiling). The top-level models using this are named:

• makefile.main.ves

This may have to change in the future, as using autoconf will probably mean running autoconf as a tool under Vesta to generate the configure script. This would make the top-level model for makefile generation specific to one platform.

Variant Suffixes

In some cases, there are variant builds which add an additional string before ".main.ves"

• os_cpu_variant.main.ves

  os_cpu_osrev_variant.main.ves

For example, the Vesta repository has a variant build with performance data recording and debugging features. The models for building this end in "_perf.main.ves".