Back home or onto module methods
-
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:
- sherpa.distribution - File distribution methods (tarball, fossil, git, etc.)
- sherpa.buildsystem - Driver for configuration, builds, and installs (autoconf, cmake, sak, etc)
- sherpa.module - Record keeping, journaling, and repackaging
A typical recipe will look like this:
sherpa::recipe udp { module udp distribution fossil toolset tea fossil_url {http://fossil.etoyoc.com/fossil/tcludp} package_binary 1 package_binary_tk 0 package_version 1.0.10 destroot_capabable 0 }
sherpa::recipe is a tcl command. It's the wrapper around the creation of the recipe object. It's arguments are:
- name
- properties
- class name | tclOO body
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:
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 http://fossil.etoyoc.com/fossil/tcl fossil_tag release } { method build-options {} { return [my <toolset> tcl get config_flags] } }
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.)