Differences between revisions 1 and 2
Revision 1 as of 2005-06-27 03:18:54
Size: 1426
Editor: KenSchalk
Comment: Dump of some notes from my PDA
Revision 2 as of 2005-06-27 23:48:34
Size: 4149
Editor: KenSchalk
Comment: Add more explanation fo the problem
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
= Version Selection =

Some SDL models which builds use in turn import other models. A good example is {{{std_env}}} which improts versions of different bridges, compilers and other tools, libraries, etc. Such models usuall allow the caller to specify ''overrides'' as parameters to change the versions of these sub-components which gets 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 Problem =

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.
Line 7: Line 27:
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 configuration from the flexibility of a programming language would make writing tools that understand/generate a configuration much easier.
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.
Line 26: Line 44:
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. 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.

Version Selection

Some SDL models which builds use in turn import other models. A good example is std_env which improts versions of different bridges, compilers and other tools, libraries, etc. Such models usuall allow the caller to specify overrides as parameters to change the versions of these sub-components which gets used. To see how this works, look at:

See also [http://www.vestasys.org/doc/man/html/voverrides.5.html#TransPkgOvsSect "Transient Package Overrides" in the voverrides(5) man page].

The Problem

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 porgram (instead have well-defined selection semantics so programs can understand & manipulate them)

Tricky parts:

  • may need to use different versions of the same thing in different parts of a buils (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".