Sugar Labs

Sugar Network/Recipe Specification

< Sugar Network
Revision as of 08:22, 12 April 2011 by Alsroot (talk | contribs) (→‎Examples)

The recipe specification file is an analog of scenario files in regular GNU/Linux distributions, like .spec files in RPM. It is the cornerstone of SDK, everything on sweet project level depends on the recipe file. For activities, activity/activity.info, an inherited recipe file name, is supported.

Recipe structure

Recipe file is an ini format configuration file that might consist of several sections:

Use case sections

Recipe should contain at least one use case section to describe how the sweet might be used.

Use case sections are named: 

[use-case-type[:sub-name]]

Where use-case-type is one of the following sub sections and sub-name is an optional identifier used if there are more than one sections of the same type.

Regardless of the type, a use case section (or one of them) should contain the following options.

Common options

implement = <sweet> [; ...]

Required. The list of sweets current project is implementing. 

associate = <sweet> [; ...]

Optional. The list of sweets whose implementations might be considered as additional implementations for current one. 

name = <name>

Optional. Free-form name. (It is equal to the sweet, by default.) 

summary = <one-line-description>

Required. Short descriptive line. 

description = <multi-line-description>

Optional. Long descriptive text. To wrap long text, all lines starting from the second, should start with spaces. This field is equal to summary by default. 

license = <license-name>

Required. The license. Short license names from Fedora naming scheme are welcome. 

homepage = <url>

Required. Sweet project home page. 

icon = <icon-file-name>

Optional. Path to the icon file starting from the path where the recipe file is located. 

category = <category> [; ...]

Optional. A classification for the sweet using values defined by freedesktop.org menu specification. 

tags = <tag> [; ...]

Optional. Tags give more context in which to group the sweet. This is used to allow users to find sweets more easily. 

version = <version-number>

Required. Current version of the sweet using 0install version format. 

stability = <stability-level>

Required. Stability level of the current version. Values conform to 0install stability levels and could be:

  • insecure
  • buggy
  • developer
  • testing
  • stable

[Activity]

This section type should be present only in activities. 

activity_version = <version>

Required. Option is deprecated, use version instead, but should be still present to not fail in current sugar. It will be useful to use expansion like %(version)s for this option. 

bundle_id = <bundle-id>

Required. See activity.info file specification. This option is deprecated, use sweet instead, but it should still be present to not fail in current sugar. 

icon = <icon-file-name-without-suffix>

Required. Behaviour from activity.info is supported (value should not have a .svg suffix, and the icon file can be found only in the activity subdirectory) and, while deprecated, it needs to be used to not break backwards compatibility. For the remaining cases, the regular icon behaviour should be used instead. 

exec = <shell-command>

Required. Sugar will pass additional command line arguments to this command. 

mime_types = <mime-type> [; ...]

Optional. List of mime types supported by the activity. It's used when opening a file from the web, or to present to the user a list of activities that can open a certain Journal object. 

requires = <dependency> [(=|>=|<) <version>] [; ...]

Optional. List of dependencies that should exist in run-time before launching the activity.

[Application]

Application to run out of Sugar Shell. 

exec = <shell-command>

Required. The relative path of an executable command inside the implementation that should be executed by default when the sweet is run. Command can have optional arguments. 

requires = <dependency> [(=|>=|<) <version>] [; ...]

Optional. List of dependencies that should exist in run-time before launching the application.

[Library]

binding = [prepend|append|replace] <variable-name> [<insert-text-to-prepend-variable-value>] [; ...]

Required. The environment variables 0install should export to the process that uses this sweet. 

requires = <dependency> [(=|>=|<) <version>] [; ...]

Optional. List of dependencies the library is based on.

Archive sections

Archive section describes the tarball that will contain the sweet implementation.

If there are not any archive sections, the sweet implementation consists of only one archive that includes the entire %(DESTDIR)s directory (excluding temporary files). At the same time, the sweet implementation might be split into several archives.

Possible use cases:

  • To save storage space or bandwidth when some tarballs will contain any-arch data that are common for all platforms, and another tarball will contain binaries for a particular platform.

All archive sections are named: 

[Archive[:sub-name]]

And contain the following options: 

include = <glob-pattern> [; ...]

Optional. Glob pattern for files to include in the archive. Path related patterns will be processed starting from the %(DISTDIR)s/%(PREFIX)s directory. By default, all files are assumed. 

exclude = <glob-pattern> [; ...]

Optional. Like the include option, but used for excluding files from the archive. In addition, various temporary files will be excluded, like .bak or .pyc. 

langs = <lang-name> [; ...]
include[<lang-name>] = <glob-pattern> [; ...]
exclude[<lang-name>] = <glob-pattern> [; ...]

Optional. A special form of include/exclude options that are intended to create separate, per locale, archives. If a language is mentioned in the langs list, but doesn't have any include[]/exclude[] options, include/exclude will be used (in that case, using the special LANG variable makes sense). 

arch = <arch>

Optional. Makes sense only for binary archives, and can contain:

  • all for noarch (by default)
  • any for binaries to use the current architecture

Auxiliary sections

Sections that don't describe recipe components.

[Build]

This section is required if the sweet needs additional work in order to prepare a ready-to-use installation. To prepare valid sweets, it is important to use predefined constants for options that contain shell commands. All shell commands will be executed from the %(BUILDDIR)s directory.

NOTE The commands in this section will be executed, not only in the developer's environment, but also in the user's, if a proper binary wasn't found; so move all development-related commands, like autogen.sh, to the [Source] section. 

requires = <dependency-name> [(=|>=|<) <version>] [; ...]

Optional. This defines what dependencies should be present before building the sweet from sources. Note that requires from [Component] sections are not auto included in the build-time dependencies. 

clean = <shell-command>

Optional. Cleanup build environment before running configure command. 

configure = <shell-command>

Optional. Shell command to configure sources before building, e.g., invoking the configure script in auto-tools-based projects. If the source code does not require a configuration stage, this option could be omitted. 

make = <shell-command>

Optional. Shell command to make binaries from sources. If the source code does not require a making stage, this option could be omitted. 

install = <shell-command>

Required. Shell command to place files that are ready for distribution into the %(DESTDIR)s directory. If install is missing, the entire %(BUILDDIR)s (excepting temporary files) will be copied.

[Source]

exec = <shell-command>

Optional. Execute an external program to create sources tarball. Option might be used, e.g., to run make dist command. After executing the exec shell command, sweets will pick up a newly appearing tarball if it was created in the sweet root directory. 

include = <glob-pattern> [; ...]
exclude = <glob-pattern> [; ...]

Optional. If the exec option was not used, all files will be bundled and these glob patterns might be used to concretize the selection. 

requires = <dependency> [(=|>=|<) <version>] [; ...]

Optional. The dependencies that should be present before creating sources tarball. For example, if the exec command generates .c files from .vala, the vala dependency should be mentioned in the requires option.

Predefined options

Options defined within [Build] section:

  • BUILDDIR where the build happens, directory contains un-tarred sources bundle. This variable can be used in binding options as well. During the local build, it will point environment variables to the root of sources directory.
  • DESTDIR temporary path to place installed files before bundling them
  • PREFIX should be used as installation prefix path, e.g., for ./configure --prefix
  • CFLAGS default gcc CFLAGS
  • CXXFLAGS default gcc CXXFLAGS

In sections that contain a langs option:

  • LANG current language while building per language implementation

Examples

Python activity

Python-based activity with standard Sugar Platform dependencies. 

[Activity]
implement = cartoon-builder
name      = Cartoon Builder
summary   = Create your own cell-animation sequences
license   = GPLv2+
homepage  = http://wiki.sugarlabs.org/go/Activities/Cartoon_Builder

version   = 11.4.9-pre3
stability = testing

icon      = activity-cartoonbuilder
exec      = sugar-activity activity.CartoonBuilderActivity

# original activity.info options
bundle_id = com.ywwg.CartoonBuilderActivity
activity_version = %(version)s

Python library

A python-based library that could be used as is, or as an activity dependency. 

[Library]
implement = libjournal
name      = libjournal
summary   = Hight level library to create your own Journal-like activity
license   = GPLv3+
homepage  = http://wiki.sugarlabs.org/go/Activity_Team/Services/Journal
version   = 1
stability = testing
requires  = toolkit
binding   = PYTHONPATH

C-based library

[DEFAULT]
depends   = glib; gconf; libgee >= 0.5; gtk+ >= 2.12; pango >= 1.20; librsvg

[Library]
implement = polyol
name      = polyol
summary   = Intermediate level GObject based libraries for Sugar
description = Polyol is a set of libraries that are written in Vala.
            Libraries are intended to provide high-level C API to basic Sugar
            features including Gtk based user interface. Applications that are
            linked against Polyol, interact with sugar processes
            (like shell, datastore, etc.) via DBus.
license   = LGPLv3+
homepage  = http://wiki.sugarlabs.org/go/Activity_Team/Polyol

version   = 1
stability = testing

binding   = LD_LIBRARY_PATH lib
            PKG_CONFIG_PATH lib/pkgconfig
            VAPIDIR share/vala/vapi
requires  = %(depends)s

[Archive]
arch      = any

[Build]
requires  = %(depends)s; pkg-config; cmake; make; gcc-c
configure = cmake -D CMAKE_INSTALL_PREFIX=%(PREFIX)s
                  -D PYTHON_SITEDIR=%(PREFIX)s/python
                  -D COMPONENTS="collab;ds;env;gui;shell;toolkit"
                  -D BINDING=python
                  -D CMAKE_C_FLAGS:STRING="%(CFLAGS)s"
                  .
make      = make
install   = make DESTDIR=%(DESTDIR)s install
Retrieved from "https://wiki.sugarlabs.org/index.php?title=Sugar_Network/Recipe_Specification&oldid=64753"