|Deletions are marked like this.||Additions are marked like this.|
|Line 47:||Line 47:|
= Discussion =
Some SDL models which builds use in turn import other models. A good example is std_env which imports versions of different bridges, compilers and other tools, libraries, etc. Such models usually allow the caller to specify overrides as parameters to change the versions of these sub-components which get used. To see how this works, look at:
[http://pub.vestasys.org/cgi-bin/vestaweb?path=/vesta/vestasys.org/vesta/release/12.pre13/6/pkg_ovs.ves The pkg_ovs.ves file in Vesta pre-releases]
[http://pub.vestasys.org/cgi-bin/vestaweb?path=/vesta/vestasys.org/vesta/release/12.pre13/6/linux_i386.main.ves#L38 The way that model is used in top-level models to construct the pkg_ovs variable] which is then used as a parameter to the env_build function returned by the std_env model
[http://pub.vestasys.org/cgi-bin/vestaweb?path=/vesta/vestasys.org/platforms/linux/redhat/i386/std_env/9/build.ves#L123 The definition of the env_build function in the std_env package] which uses this parameter for alternate versions of bridges, libraries, etc.
See also [http://www.vestasys.org/doc/man/html/voverrides.5.html#TransPkgOvsSect "Transient Package Overrides" in the voverrides(5) man page].
The handling of version overrides has been written in SDL code. There are several problems with this:
- Other, non-SDL programs want to understand the currently selected version of different components. For example, the user is often interested in asking "which version of component X is my build using?" Only the SDL code knows which version is actually being used, and only at run-time. You can write another program which parallels the SDL override logic, but that's ugly, prone to errors, and becomes a maintenance headache.
Other, non-SDL programs want to change the currently selected version of different components. For example, you might want to automatically generate overrides for new versions of certain components, possibly based on a criteria such as attributes. vupdate can't do that unless you're directly changing the model which already imports them, which you usually aren't with overrides. Another possibility is writing a GUI that allows the user to change the versions they have selected.
- It has led to multiple subtly different forms of version overrides, which can be confusing for users
Version selection is a fairly simple problem. While it is possible to implement it in SDL, you don't need all the flexibility that SDL gives you to solve the problem of version selection.
New version selection
Vesta builds would be easier to configure if the selection of which versions to use (overrides, etc.) was separated from the SDL code that defines the build flow. Removing the selection of versions from the flexibility of a full programming language would make writing tools that understand/generate a configuration much easier.
Aspects to keep:
- only specific versions (not references to "latest")
- only taken from a versioned source file
- versioned like other source files
- take base config, add changes
Aspects to change:
selection semantics defined by SDL programs (instead have well-defined selection semantics so programs can understand & manipulate them)
- may need to use different versions of the same thing in different parts of a builds (e.g. different versions of a shared library during different tool invocations)
SDL still needs some way to access the selected versions of different components. This could be done through a new import-like syntax. Another possibility would be feeding the version selection to the top-level model as its initial dot. Either way, we're creating a new namespace from which the SDL will somehow get the selected versions.
We need to associate the version selection file with the top-level model. (We wouldn't want the user to have to specify both at build time.) Maybe name the version selection file the same as the model, only ending in ".vsel".