Back [home] or onto [module methods]
<li>

Sherpa Recipes are TclOO objects which conduct the download, unpacking, configuration, installation, and repackaging of code.

They are a combination of three different types of objects:
<ul>
<li>sherpa.distribution - File distribution methods (tarball, fossil, git, etc.)
<li>sherpa.buildsystem - Driver for configuration, builds, and installs (autoconf, cmake, sak, etc)
<li>sherpa.module - Record keeping, journaling, and repackaging
</ul>

A typical recipe will look like this:

<verbatim>
sherpa::recipe udp {
  module udp
  distribution fossil
  toolset tea
  fossil_url
  package_binary 1
  package_binary_tk 0
  package_version 1.0.10
  destroot_capabable 0
}
</verbatim>

<b>sherpa::recipe</b> is a tcl command. It's the wrapper around the creation of the recipe object. It's arguments are:
<ul>
<li>name
<li>properties
<li>class name | tclOO body
</ul>

If the last argument is a single list element, it is assumed to the name of a pre-built class. If it is any longer it is interpreted as a TclOO define for a new class.

A more complex example:

<verbatim>
oo::class create sherpa.buildsystem.core {
  superclass sherpa.distribution.fossil sherpa.buildsystem.autoconf sherpa.module

  method path-source {} {
    return [file join [my module_path] [my <toolset> tcl get platform_source_dir]]
  }
  method sherpa_vfs_install path {}
}

sherpa::recipe tcl {
  class sherpa.buildsystem.core
  package_name Tcl
  package_version 8.6.4
  fossil_url
  fossil_tag release
} {
  method build-options {} {
    return [my <toolset> tcl get config_flags]
  }
}
</verbatim>

In this case, we are defining a new family of recipes. And even with the new family, each recipe still needs to define a custom set of build options. And... because this is the Tcl core, we don't provide the customary method for packing the contents into a VFS. (There's a separate system for populating the VFS with the boot code for Tcl.)