new std_env call

std_env is now called with a new addons param like this:

. = std_env()/env_build(addons, pkg_ovs, bridge_params);

addon collection wrapper

you need to take your standard, pre-addon style bridge and wrap it with an addons keyword during collection.

Eg collector.node.ves:

// this is an addon, so import addon.ves not build.ves
    import
        addon_file_func = addon.ves;
{
  return [ contents = [ addons = addon_file_func ] ];
}

More detail tbd.

keywords

the std_env addon system recognizes several keywords indicating the type of addon. Each gets its own treatment:

component_models (overridden by pkg_ovs/components;
                  items in here get evaluated and results added under ./components)
bridges          (overridden by pkg_ovs/bridges;
                  items in here get evaluated and results added directly under .
                  it is expected they add ./my_bridge_name/funcs)
bridge_params    (overridden by the bridge_params arg to env_build() itself;
                  items in here keyed by my_bridge_name get passed to that
                  bridge's build func or model_file)
libs             (items in here get evaluated and results added under ./libs)
env              (items in here are not evaluated and get added directly under . )
root             (items in here are not evaluated and get added under ./root)
prereqs          (things to build before building this one)

cxx.ves on scooter.cx uses many of these.

std_env addons directly to dot

whatever your model_file (eg, my_pkg/pkg/build.ves) returns gets directly added under ./addons

std_env bridge type addons -- addon bridge wrapper

Your bridge's standard model_file (eg, my_bridge/pkg/build.ves) probably already exists.

Now we add an addon.ves file as a wrapper. It has to return [ bridges = [ my_bridge_name = build_bridge ] ] so that the addon sees it as a bridge.

An addon.ves model file might look like this:

import
   bridge_build = build.ves;  // standard bridge ves file you already have
{
 return [ bridges       = [ my_bridge_name = bridge_build ],
          bridge_params = [ my_bridge_name= [ root = <"perl",> ] ],
        ];

}

bridges and bridge_params are keywords in the std_env addon system and cannot be changed.

bridge_params contains a root key which addon recognizes. See below.

my_bridge_name is whatever you want. People will invoke this bridge via ./my_bridge_name/func.

bridge_build can be any name you want and is not visiable to bridge users.

root

The example addon.ves above returns a bridge_params key containing a root sub-key. The addon env_build() [ref new_std_env internal only] recognizes this root and uses as a trigger to call build_root() for you, replacing your string IDs w/ real root files.

The build_root() func has not changed with the new addon style std_env and so is the same as the one defined here: /vesta/vestasys.org/platforms/linux/redhat/i686/std_env/latest/build.ves (latest = 9 as of this writing). The return value from this model file normally is set to dot, so then build_root() lives in ./build_root().

build_root() takes a text list of names and expects to find a root() function under dot here ./components/$name/root() for each name.

addon std_env has another variant of build root, build_addon_root(), that looks for names to build in ./addons/$name/components. It calls the standard build_root() on those names.

addon prereqs

Addons can have a prereqs keyword [somehwere] to indicate that the prereq has to be loaded before the addon being considered.

Example

./AddonExample

./IdealExample

Wiki

User