Changes

== Recipes ==

== Recipes ==

In some cases, e.g., to save storage space or bandwidth, it is useful to split packaged application into several parts when some parts will be common. Most usual is having any-arch data and binaries sub-services, i.e., the final service will depend on data sub-service (one implementation per application release) and sub-service with binaries (implementations per arch per application release). But it's not possible to always use sub-services. Applications could assume that data is placed in a particular relative path from launched binaries, and if there is no way to set data locatation via environment bindings, sub-services are useless and recipes will help.

In some cases, e.g., to save storage space or bandwidth, it is useful to split packaged application into several parts when some parts will be common. Most usual is having any-arch data and binaries sub-packages, i.e., the final service will depend on data sub-package (one implementation per application release) and sub-packages with binaries (implementations per arch per application release). But it's not possible to always use sub-packages. Applications could assume that data is placed in a particular relative path from launched binaries, and if there is no way to set data location via environment bindings, sub-packages are useless and recipes will help.

Use ''recipe'' option to declare a service as a recipe:

Use ''recipe'' option to declare a (sub)packages as a recipe:

   [Service]

   [Package]

   recipe = <component-name> [; ...]

   recipe = <component-name> [; ...]

   ...

   ...

Only the following options make sense for component sections, and they cannot be used in the recipe section. Other options that the recipe component section will inherit from the recipe section:

Being a recipe, package section cannot contain files related options (since package itself does not contain any tarballs directly, only via recipe components), these options could be set only in components:

* langs

* langs

* arch

* arch

* slots

* slots

The same component could a part of different recipes. In that case, different (sub)service implementations will contain the same component tarball.

The same component could a part of different recipes. In that case, different (sub)package implementations will contain the same recipe component tarball.

The final ''[Service]'' implementation will contain tarball per component. All these tarballs will be unpacked to the same root directory. For example, having the following lines and invoking ''0sugar build'' on two platforms - x86 and x86_64 platforms, two (per arch) implementations will be created and they will use three tarballs - x86 and x86_64 tarballs from ''[binary]'' section and one common for both implementations ''[data]'' tarball.

The final package implementation will contain tarball per component. All these tarballs will be unpacked to the same root directory. For example, having the following lines and invoking ''0sugar build'' on two platforms - x86 and x86_64 platforms, two (per arch) implementations will be created and they will use three tarballs - x86 and x86_64 tarballs from ''[binary]'' section and one common for both implementations ''[data]'' tarball.

  [Service]

  [Package]

  recipe = data, binary

  recipe = data, binary

   

   

  [data]

  [data]

  include = share/*

  include = share/**

   

   

  [binary]

  [binary]

  include = bin/*, lib/*

  include = bin/**, lib/**

  main = bin/launch

  main = bin/launch

  arch = build

  arch = build