Differences between revisions 4 and 5
Revision 4 as of 2007-03-26 17:16:42
Size: 5151
Editor: ScottVenier
Comment: spam cleanup
Revision 5 as of 2016-05-17 02:41:05
Size: 5179
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
[[TableOfContents]] <<TableOfContents>>
Line 9: Line 9:
A "top-level model" is the kind given directly to the [http://www.vestasys.org/doc/man/html/vesta.1.html Vesta builder]. Typically these return values such as executable programs or some other result produced through compilers or other tools. A "top-level model" is the kind given directly to the [[http://www.vestasys.org/doc/man/html/vesta.1.html|Vesta builder]]. Typically these return values such as executable programs or some other result produced through compilers or other tools.
Line 13: Line 13:
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 [http://www.vestasys.org/doc/man/html/vesta.cfg.5.html 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. 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 [[http://www.vestasys.org/doc/man/html/vesta.cfg.5.html|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.
Line 40: Line 40:
||solaris||[http://www.sun.com/software/solaris/ Sun Solaris]||
||freebsd||[http://www.freebsd.org/ FreeBSD]||
||macos||[http://www.apple.com/macosx/ Apple's MacOS X]||
||aix||[http://www.ibm.com/servers/aix/ IBM's AIX]||
||solaris||[[http://www.sun.com/software/solaris/|Sun Solaris]]||
||freebsd||[[http://www.freebsd.org/|FreeBSD]]||
||macos||[[http://www.apple.com/macosx/|Apple's MacOS X]]||
||aix||[[http://www.ibm.com/servers/aix/|IBM's AIX]]||
Line 65: Line 65:
||deb_sarge||[http://www.debian.org/releases/sarge/ Debian sarge] (aka 3.1)||
||deb_woody||[http://www.debian.org/releases/woody/ Debian woody] (aka 3.0)||
||deb_sarge||[[http://www.debian.org/releases/sarge/|Debian sarge]] (aka 3.1)||
||deb_woody||[[http://www.debian.org/releases/woody/|Debian woody]] (aka 3.0)||
Line 70: Line 70:
||deb_etch||[http://www.debian.org/releases/etch/ Debian etch] (the current "testing" version of Debian)||
||fc4||[http://fedora.redhat.com/ Fedora Core] 4||
||deb_etch||[[http://www.debian.org/releases/etch/|Debian etch]] (the current "testing" version of Debian)||
||fc4||[[http://fedora.redhat.com/|Fedora Core]] 4||
Line 85: Line 85:
We have [http://pub.vestasys.org/cgi-bin/vestaweb?path=/vesta/vestasys.org/bridges/makefile_env a build environment which generates a make-based source kit] (rather than compiling). The top-level models using this are named: We have [[http://pub.vestasys.org/cgi-bin/vestaweb?path=/vesta/vestasys.org/bridges/makefile_env|a build environment which generates a make-based source kit]] (rather than compiling). The top-level models using this are named:
Line 89: Line 89:
This may have to change in the future, as [https://sourceforge.net/tracker/index.php?func=detail&aid=1085473&group_id=34164&atid=410430 using autoconf] will probably mean running [http://www.gnu.org/software/autoconf/ 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. This may have to change in the future, as [[https://sourceforge.net/tracker/index.php?func=detail&aid=1085473&group_id=34164&atid=410430|using autoconf]] will probably mean running [[http://www.gnu.org/software/autoconf/|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.
Line 99: Line 99:
For example, [http://pub.vestasys.org/cgi-bin/vestaweb?path=/vesta/vestasys.org/vesta/repos the Vesta repository] has a variant build with performance data recording and debugging features. The models for building this end in "_perf.main.ves". For example, [[http://pub.vestasys.org/cgi-bin/vestaweb?path=/vesta/vestasys.org/vesta/repos|the Vesta repository]] has a variant build with performance data recording and debugging features. The models for building this end in "_perf.main.ves".

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:

tru64

HP/Compaq Tru64 UNIX (aka Digital UNIX)

linux

Linux

These will probably be used in the future:

solaris

Sun Solaris

freebsd

FreeBSD

macos

Apple's MacOS X

aix

IBM's AIX

CPU Strings

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

i386

Intel 80386 and up

x86_64

x86 with 64-bit extensions (Debian calls this amd64)

alpha

Alpha

ppc

PowerPC (32-bit)

sparc

Sparc (32-bit)

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:

rh7

Red Hat 7

deb_sarge

Debian sarge (aka 3.1)

deb_woody

Debian woody (aka 3.0)

These will probably be used in the future:

deb_etch

Debian etch (the current "testing" version of Debian)

fc4

Fedora Core 4

"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".