HaikuPorter BuildRecipes

Build Recipes

Overview

A build recipe is a special kind of shell script that tells HaikuPorter the specific details about how a particular version of a port should be built and which packages should be created from the build results.

There's a two-way "communication" (using environment variables and shell functions) between HaikuPorter and the build recipe script:

Input (HaikuPorter → Build Recipe Script)

A set of environment variables is set up by HaikuPorter and passed down to the script at invocation time. These variables can be inspected by the recipe script in order to adjust details of the build configuration. Most notably, a lot of variables correspond to directories where files should be put by the build.

Additionally, several shell functions are being made available to the recipe script, which can (and should!) be invoked by the recipe in order to do some specific tasks (e.g. invoking the configure script or processing built static libraries).

Output (Build Recipe Script → HaikuPorter)

Several environment variables need to be initialized by the recipe script in order to pass information about build details back to HaikuPorter.

Additionally, shell functions implementing the different build phases have to be defined by the recipe script. HaikuPorter will invoke these functions when needed (e.g. the actual commands to be used for building a port must be defined in a shell function named BUILD).

Input

Environment Variables

Most of the environment variables passed from HaikuPorter to the build recipe script define a directory for putting a certain type of files created by the build process. Many of these can/should be passed to the configure-script used by many ports.

Whenever an absolute path is required by the build process, HaikuPorter uses the package-links folder to abstract the actual installation path, such that the resulting packages will work, no matter to which packages-folder (e.g. /boot/common/packages or /boot/home/config/packages) they are being installed.

Here's a list of all input environment variables:

• $addOnsDir: The absolute directory for add-ons.
• $appsDir: The absolute directory for applications.
• $binDir: The absolute directory for binaries.
• $buildArchitecture: The Haiku architecture HaikuPorter is running on (e.g. x86_gcc2).
• $configureDirArgs: A string containing all the standard configure options with their respective value. This can be used instead of passing all the individual variables to configure (but you should use runConfigure() instead, anyway).
• $configureDirVariables: A string containing a space separated list of names of all directory variable names.
• $dataDir: The absolute directory for data.
• $dataRootDir: The absolute base directory for data. On Haiku, this is the same as $dataDir.
• $debugInfoDir: The absolute path to the directory for debug info files.
• $developDir: The absolute path to the directory underneath of which all development-related files should be put.
• $developDocDir: The absolute base directory for development-related documentation specific to the port being built. Documentation in html- or pdf-format should be put here, manpages should be put into $manDir.
• $developLibDir: The absolute directory for development libraries (i.e. static and shared libraries provided by a devel package). Shared libraries required at runtime don't belong here, they should be put into $libDir.
• $docDir: The absolute base directory for (non-development) documentation specific to the port being built. Documentation in html- or pdf-format should be put here, manpages should be put into $manDir.
• $documentationDir: The absolute base directory underneath of which all documentation should be put. This is not a port-specific directory.
• $fontsDir: The absolute directory for fonts.
• $includeDir: The absolute directory for header files
• $infoDir: The absolute directory for documentation in info-format (which is frowned upon by Haiku ports).
• $installDestDir: An absolute path that shall be prepended to all absolute installation paths (when they are dereferenced, i.e. usually only in the 'INSTALL' function) and should be set as the 'DESTDIR' for 'make install'. This only needs to be done in the HaikuPorts cross building repository.
• $isCrossRepository: Is true if the ports tree being used is the one dealing with cross-building the bootstrap packages.
• $jobArgs: If HaikuPorter has been invoked with --jobs=<num>, this contains the job-number specification applicable to make (i.e. -j<num>)
• $jobs: The number of build jobs to run concurrently (can be set with haikuporter --jobs=<num>
• $libDir: The absolute directory for shared libraries to be used at runtime (i.e. by Haiku's runtime loader)
• $libExecDir: The absolute directory for executables that a port may invoke internally. On Haiku, this is the same as $libDir.
• $localStateDir: The absolute directory for putting files created at runtime. This corresponds to the var-hierarchy.
• $manDir: The absolute directory for man-pages. For each man section, a subdir exists underneath this directory.
• $oldIncludeDir: Another name of the absolute directory for putting header files ($includeDir).
• $portBaseDir: The absolute directory (on the build host!) of this build recipe file. This can be useful if you'd like to use local (i.e. file:///-) URLs to other ports. An example is the gcc-recipe using a local URL to reference the source directory of the binutils port (which both live in the same git repository).
• $portDir: The absolute directory (on the build host!) where the files of the current port (patches, license, recipes) can be found.
• $portFullVersion: Full version of the current port, including revision (e.g. 2.14-1)
• $portName: Name of the current port.
• $portPackageLinksDir: The absolute path to the package-links directory of this port's base (main) package. This is useful if the current port needs to reference files from another (required) ports via absolute path. Again, this make use of the package-links abstraction, such that these cross-package references will work, no matter where a specific package is installed.
• $portRevision: The revision of the current port (e.g. 1).
• $portRevisionedName: The name of the current port, extended by version and revision (e.g. grep-2.14-1)
• $portVersion: The version of the current port (e.g. 2.14).
• $portVersionedName: The name of the current port, extended by version (e.g. grep-2.14).
• $postInstallDir: The absolute directory for post-install scripts.
• $preferencesDir: The absolute directory for preflets.
• $prefix: The absolute base directory of the port (i.e. the installation location).
• $relativeAddOnsDir: $addOnsDir as a relative directory (to prefix).
• $relativeAppsDir: $appsDir as a relative directory (to prefix).
• $relativeBinDir: $binDir as a relative directory (to prefix).
• $relativeDataDir: $dataDir as a relative directory (to prefix).
• $relativeDataRootDir: $dataRootDir as a relative directory (to prefix).
• $relativDebugInfoDir: $debugInfoDir as a relative directory (to prefix).
• $relativeDevelopDir: $developDir as a relative directory (to prefix).
• $relativeDevelopDocDir: $developDocDir as a relative directory (to prefix).
• $relativeDevelopLibDir: $developLibDir as a relative directory (to prefix).
• $relativeDocDir: $docDir as a relative directory (to prefix).
• $relativeDocumentationDir: $documentationDir as a relative directory (to prefix).
• $relativeFontsDir: $fontsDir as a relative directory (to prefix).
• $relativeIncludeDir: $includeDir as a relative directory (to prefix).
• $relativeInfoDir: $infoDir as a relative directory (to prefix).
• $relativeLibDir: $libDir as a relative directory (to prefix).
• $relativeLibExecDir: $libExecDir as a relative directory (to prefix).
• $relativeLocalStateDir: $localStateDir as a relative directory (to prefix).
• $relativeManDir: $manDir as a relative directory (to prefix).
• $relativeOldIncludeDir: $oldIncludeDir as a relative directory (to prefix).
• $relativePostInstallDir: $postInstallDir as a relative directory (to prefix).
• $relativePreferencesDir: $preferencesDir as a relative directory (to prefix).
• $relativeSbinDir: $binDir as a relative directory (to prefix).
• $relativeSettingsDir: $settingsDir as a relative directory (to prefix).
• $relativeSharedStateDir: $sharedStateDir as a relative directory (to prefix).
• $sbinDir: Absolute directory for super-user binaries. On Haiku, this is the same as $binDir.
• $settingsDir: Absolute directory for settings files.
• $sharedStateDir: Absolute directory for shared state files. On Haiku, this is the same as $localStateDir, i.e. it corresponds to the var-hierarchy.
• $sourceDir: Absolute path to the source directory of the build. This contains the files implementing the actual build process (configure, Makefile, ...).
• $targetArchitecture: The Haiku architecture HaikuPorter for which the current port is being build (e.g. x86_gcc2). Unless the ports tree in use is the one related to cross-builds, this is the same as $buildArchitecture.

When the ports tree for cross-builds is active, there are some more variables available:

• buildMachineTriple: The machine-triple for the machine HaikuPorter is running on (e.g. i586-pc-haiku_gcc2)
• buildMachineTripleAsName: The machine-triple for the machine HaikuPorter is running on as a name usable in requires/provides definitions (e.g. i586_pc_haiku_gcc2)
• crossSysrootDir: The cross-sysroot directory (only for cross builds, e.g. /boot/cross-sysroot/x86_gcc2)
• targetMachineTriple: The machine-triple for the machine this port is being built for (e.g. i586-pc-haiku_gcc2)
• targetMachineTripleAsName: The machine-triple for the machine this port is being built for as a name usable in requires/provides definitions (e.g. i586_pc_haiku_gcc2)

TODO: it would be useful to be able to specify some kind of prefix for all of the above variables, as otherwise there can be namespace clashes with the actual build process used by specific port (git is an example).

Shell Functions

The following shell functions are defined by HaikuPorter to make them available to the build recipe script:

addAppDeskbarSymlink()

• usage: addAppDeskbarSymlink <appPath> [ <entryName> ]
• purpose: Creates a Deskbar symlink for an application.
• params:
  • appPath: The absolute path to the application executable.
  • entryName: The name of the application as it shall appear in the Deskbar. Can be omitted, in which case the file name of the application executable is used.

addPreferencesDeskbarSymlink()

• usage: addPreferencesDeskbarSymlink <appPath> [ <entryName> ]
• purpose: Creates a Deskbar symlink for a preferences application.
• params:
  • appPath: The absolute path to the application executable.
  • entryName: The name of the application as it shall appear in the Deskbar. Can be omitted, in which case the file name of the application executable is used.

defineDebugInfoPackage()

• usage: defineDebugInfoPackage [ --directory <toDirectory> ] <basePackageName> <path> ...
• purpose: Defines a debug info package for another package. Must be invoked at top level (i.e. not in one of the action functions). The specified base package contains the specified files from which debug infos shall be extracted. At the end of the installation phase (i.e. after 'INSTALL' returns) the debug infos are extracted into separate files and moved into a respective debug info package.
• params:
  • toDirectory: The path to the directory where the debug info files shall be placed. The default is $debugInfoDir.
  • basePackageName: The name of the base package the files belong to. This also defines the name of the debug info package (<basePackageName>_debuginfo) and its dependency.
  • path: The path to a file from which the debug info shall be extracted. An arbitrary number of files can be specified.

extractDebugInfo()

• usage: extractDebugInfo <path> <debugInfoPath>
• purpose: Extracts the debug info from a file into a debug info file.
• params:
  • path: The path to the file from which to extract the debug info.
  • debugInfoPath: The path of the to-be-created debug info file. The containing directory (and all missing ancestor directories) are created, if necessary.

fixDevelopLibDirReferences()

• usage: fixDevelopLibDirReferences <file> ...
• purpose: Replaces instances of $libDir in the given files with $developLibDir. This is useful for fixing a <portname>-config script with respect to where it locates development libraries. Usually, those believe libraries to be found in $libDir, but on Haiku, those live in $developLibDir.

fixPkgconfig()

• usage: fixPkgconfig
• purpose: Moves pkgconfig-subfolder from $libDir to $developLibDir and adjusts all files in there to reference libraries via $prefix/develop/lib and headers via $prefix/develop/headers.

packageEntries()

• usage: packageEntries <packageSuffix> <entry> ...
• purpose: Moves the given entries to the packaging directory for the sibling package specified by packageSuffix. In effect, the given entries will not be put into the main package, but they will be put into the sibling package instead.
• params:
  • packageSuffix: The suffix of the sibling package where the entries should be moved to.
  • entry: Specifies a single entry to be moved from the main package to the sibling package. The given entry paths can be absolute or relative to $prefix.

prepareInstalledDevelLib()

• usage: prepareInstalledDevelLib <libBaseName> [ <soPattern> [ <pattern> ] ]
• purpose: Symlinks all libraries matching a given base name from $libDir to $developLibDir if they match the soPattern and moves the rest (e.g. static libraries) to $developLibDir.
• params:
  • libBaseName: The base name of the library, e.g. "libfoo".
  • soPattern: The glob pattern to be used to enumerate the shared library entries. Is appended to $libDir/${libBaseName} to form the complete pattern. Defaults to ".so*".
  • pattern: The glob pattern to be used to enumerate all library entries. Is appended to $libDir/${libBaseName} to form the complete pattern. Defaults to ".*".

prepareInstalledDevelLibs()

• usage: prepareInstalledDevelLibs <libBaseName> ...
• purpose: Invokes prepareInstalledDevelLib() for all given library base names (using the defaults for soPattern and pattern).

runConfigure()

• usage: runConfigure [ --omit-dirs <dirsToOmit> ] <configure> <argsToConfigure> ...
• purpose: Helper function to invoke a configure script with the correct directory arguments. params::
  • configure: The configure program to be called.
  • dirsToOmit: Space-separated list of directory arguments not to be passed to configure, e.g. "docDir manDir" (as a single argument!).
  • argsToConfigure: The additional arguments passed to configure.

Output

Environment Variables

These are the global (i.e. one instance per port) environment variables recognized by HaikuPorter-

BUILD_PACKAGE_ACTIVATION_PHASE

• Type: String - one of ['BUILD', 'TEST' or 'INSTALL']
• Purpose: Tell HaikuPorter in which build phase the build package(s) should be activated. By default, this happens just before the BUILD phase, but if a port depends on being able to execute its own binaries during the build (autoconf is an example), this must happen at a later phase (usually INSTALL).
• Required: No
• Default: 'BUILD'

DISABLE_SOURCE_PACKAGE

• Type: YesNo - one of ['yes', 'true', 'no', 'false'], case insensitive
• Purpose: Normally, HaikuPorter creates a source package for every port. This option can be used to disable the creation of that source package. This is used mainly for packages where the source and resulting package would be mostly identical. The main two cases are packages which are just encapsulating existing binaries, and packages that contains only scripts that don't need to be compiled.
• Required: No
• Default: 'no'

HOMEPAGE

• Type: List of URLs, one per line
• Purpose: Specify one or more websites that are homepages for this port.
• Required: Yes
• Default: None

MESSAGE

• Type: String
• Purpose: Specifies a message to be shown and acknowledged by the user (i.e. packager) before this port will be built.
• Required: No
• Default: None

REVISION

• Type: Positive Integer
• Purpose: Defines the revision of the build recipe (which is an addition to the version of the port). Whenever something is changed in the recipe that has an effect on the built packages (basically everytime the build recipe is changed), this number has to be incremented. Additionally, whenever a patch files is changed, this number has to be incremented, too.
• Required: Yes
• Default: 1

The following set of environment variables exists for each defined source archive, the first set of variables is named like shown here, the second set gets a _2 suffix, the third a _3 suffix and so on.

NOTE: most ports only have one source archive, so they don't need the additional sets.

CHECKSUM_SHA256

• Type: SHA256-checksum
• Purpose: Defines the SHA256-checksum that shall be used by HaikuPorter for validating the downloaded source archive.
• Required: Yes, unless the port does not use a source archive (for instance when the sources are fetched from a version control repository).
• Default: None

PATCHES

• Type: String
• Purpose: Specify one or more patch files to be applied to the sources of this port. This is deprecated in favour of making use of the implicit git repository that is created for ports using a source archive (and the corresponding patchset).
• Required: No
• Default: None

ADDITIONAL_FILES

• Type: String
• Purpose: Specify one or more additional files (or directories) to be made available at "$portDir/additional-files" when building the port. The names supplied here are relative to the additional-files directory of the port. Examples would be RDEF files or post install scripts not provided via the patchset.
• Required: No
• Default: None

SOURCE_DIR

• Type: String
• Purpose: Specify the subdirectory where the sources are after the source archive has been unpacked. Most ports should use '$portVersionedName', as that seems to be the most popular way of archiving the sources. If a port pulls in a large source archive but only uses a subdirectory of that itself, the relative path to that subdirectory can be specified here (e.g. for gcc 2 '$portVersionedName/legacy/gcc' is used). Only the content of the given subdirectory ends up in the source package for the port. When HaikuPorter invokes any of the shell functions provided by the recipe, it will set the current working directory to the source directory.
• Required: No
• Default: None

SOURCE_FILENAME

• Type: String
• Purpose: Can be used to specify a local filename for the source archive. This is useful if the URLs from where the source is fetched doesn't provide a proper filename (e.g. http://sw.example.org/cool-stuff-1.3/download).
• Required: No
• Default: None

SOURCE_URI

• Type: String
• Purpose: Specify one or more URIs for downloading the respective source archive from. SOURCE_URI can provide more than one URIs (one per line), all of which are expected to provide exactly the same file. If a port requires more than one source archives, it has to provide the URIs for the second archive in SOURCE_URI_2.
• Required: Yes
• Default: None
• URI-Types for Download: The following URI-types are supported for downloading source archives - plain files (which do not need to be unpacked) must be marked with a '#noarchive'-suffix:
• http://, https:// and ftp://: Download of source archive via wget
• /...: Copying of source archive (or file) from local disk.
• URI-Types for Checkout: When downThe following URI-types are supported for doing a checkout/clone of the source from a VCS repository (any particular revision can be specified as a '#<revision>' suffix):
• bzr://: Download via checkout of Bazaar repository.
• cvs://: Download via checkout of CVS repository. The required CVS module must be given as the last path component of the URI.
• fossil://: Download via cloning of Fossil repository.
• git://, git+...://: Download via cloning of Git repository.
• hg://, hg+...://: Download via cloning of Mercurial repository.
• svn://, svn+...://: Download via checkout of Subversion repository.

Finally, there is a set of output variables that can be set per-package. A sibling package can be defined by extending one of these variables with _<packageSuffix>. If for instance you set SUMMARY_devel='Development files for foo' in the foo-recipe, a sibling package foo_devel will be created alongside of the base package named foo.

Each sibling package inherits all the variables from the base package, but can override them individually by providing a value in <variable>_<packageSuffix>.

This is the set of per-package variables:

ARCHITECTURES

• Type: One or more of ['all', 'arm', 'ppc', 'x86', 'x86_gcc2', 'x86_64', 'any', 'source'], separated by space.
• Purpose: Specifies the state of this port on the given architectures. Packages that have no architecture-specific binaries (e.g. a Perl script) would be marked with "any", source packages with "source". For packages with architecture-specific content, each of the machine architectures given in the list can be prepended by either '?' or '!', which marks the package as being untested or broken on that architecture respectively. "all" may also be specified similarly, to declare a status for all machine architectures at once. (This can be overridden by adding items after it, e.g. "all !x86_gcc2" indicates the recipe can or should be built for all architectures except x86_gcc2.) As an example: ARCHITECTURES="x86_gcc2 ?x86 !ppc" means that this package works on x86_gcc2, has not been tested (but is expected to work) on x86 but is known to be broken on ppc.
• Required: Yes
• Default: None
• Remarks: ARCHITECTURES may be "any" or "source" or any combination of one or more of the other possible choices. For historical reasons the preferred order is: ARCHITECTURES="x86_gcc2 x86 x86_64 arm ppc" but in most cases arm and ppc are not even mentioned.

BUILD_PREREQUIRES

• Type: Multiline-String, one required_entity-specification per line (empty lines will be ignored). For details on required_entity, please consult Building Packages.
• Purpose: Defines the set of commands that will be executed on the build host during the build process. Usually, this will be tools like gcc, binutils, make, sed, grep, etc.
• Required: No
• Default: ""

BUILD_REQUIRES

• Type: Multiline-String, one required_entity-specification per line (empty lines will be ignored). For details on required_entity, please consult Building Packages.
• Purpose: Defines the set of development libraries (or other files with a similar purpose) that are required during the build process. Usually, this will be one devel-library specification for every library the built package depends on.
• Required: No
• Default: ""

CONFLICTS

• Type: Multiline-String, one required_entity-specification per line (empty lines will be ignored). For details on required_entity, please consult Building Packages.
• Purpose: Defines a list of things (other packages, commands, libraries, etc.) that this package conflicts with.
• Required: No
• Default: ""

COPYRIGHT

• Type: Multiline-String, one copyright per line, each starting with a year (empty lines will be ignored).
• Purpose: Specifies the copyright(s) on this port.
• Required: Yes
• Default: ""

DESCRIPTION

• Type: Multiline-String (empty lines at the beginning and end will be ignored, use \ to wrap lines).
• Purpose: Provides a detailed description of the port. If a port provides more than one package, they usually share the description.
• Required: Yes
• Default: None

FRESHENS

• Type: Multiline-String, one required_entity-specification per line (empty lines will be ignored). For details on required_entity, please consult Building Packages.
• Purpose: Specifies that this package will freshen (override) one or files of the given package, command, etc.
• Required: No
• Default: ""

GLOBAL_WRITABLE_FILES

• Type: Multiline-String, one global_writable_file_info-specification per line (empty lines will be ignored). For details on global_writable_file_info, please consult Building Packages.
• Purpose: Defines one or more global writable files or directories, which are expected to be written to when the program provided by the package executes. This can for instance be a settings file or a directory for cache files.
• Required: No
• Default: ""

LICENSE

• Type: Multiline-String, one license per line (empty lines will be ignored)
• Purpose: Defines the applicable licenses for the port.
• Required: Yes
• Default: None

The licenses should either be picked from the list in /system/data/licenses, or provided next to the recipe in a licenses folder as text file for inclusion inside the package. Use the names from http://spdx.org/licenses/ if possible.

PACKAGE_GROUPS

• Type: Multiline-String, one group per line.
• Purpose: Defines one or more Unix groups that are required by the package. These groups will be created upon installation of the package.
• Required: No
• Default: ""

PACKAGE_USERS

• Type: Multiline-String, one user-specification per line (empty lines will be ignored). For details on user, please consult Building Packages.
• Purpose: Defines one or more Unix users that are required by the package. These users will be created upon installation of the package.
• Required: No
• Default: ""

POST_INSTALL_SCRIPTS

• Type: Multiline-String, one prefix-relative file path per line (empty lines will be ignored).
• Purpose: Specifies shell scripts that are to be executed when the package is installed (or updated). Can be used to e.g. generate host specific data (like SSH host keys).
• Required: No
• Default: ""

PROVIDES

• Type: Multiline-String, one entity-specification per line (empty lines will be ignored). For details on entity, please consult Building Packages.
• Purpose: Defines the set of commands, libraries, development-libraries, virtual entities, etc. that this package provides. Amongst these, every package provides itself (i.e. PROVIDES must include an entity matching the package name.
• Required: Yes
• Default: None

REPLACES

• Type: Multiline-String, one required_entity-specification per line (empty lines will be ignored). For details on required_entity, please consult Building Packages.
• Purpose: Defines the set of commands, libraries, packages, etc that this package replaces. This is for instance useful when a package has been split, as you can tell the package manager which packages need to be installed instead of the package that got split.
• Required: No
• Default: ""

REQUIRES

• Type: Multiline-String, one required_entity-specification per line (empty lines will be ignored). For details on required_entity, please consult Building Packages.
• Purpose: Defines the set of commands, libraries, packages, virtual entities, etc. that are required at runtime by the packaged software. The package can only be installed when all its requirements are fulfilled.
• Required: No
• Default: ""

SUMMARY

• Type: String, single line, preferably not exceeding 70 characters in length.
• Purpose: Gives a precise purpose of this package. For ports that provide more than one package of general type, each of these packages should have a (slightly) different summary, expressing what exactly itself is providing. For all non-generic package types, HaikuPorter will automatically add a suffix to the inherited summary:
  • debug: The suffix ' (debug info)' will be appended to the inherited summary of debug packages.
  • devel: The suffix ' (development files)' will be appended to the inherited summary of development packages.
  • doc: The suffix ' (documentation)' will be appended to the inherited summary of documentation packages.
  • source: The suffix ' (source files)' will be appended to the inherited summary of source packages.
• Required: Yes
• Default: None

SUPPLEMENTS

• Type: Multiline-String, one required_entity-specification per line (empty lines will be ignored). For details on required_entity, please consult Building Packages.
• Purpose: Defines the set of commands, libraries, packages, etc that this package supplements. This is for instance useful when a library port provides a sibling package containing just the python bindings for that library. This sibling package could specify SUPPLEMENTS=python in order to be automatically selected for installation alongside the base package when python is already installed.
• Required: No
• Default: ""

USER_SETTINGS_FILES

• Type: Multiline-String, one user_settings_file_info-specification per line (empty lines will be ignored). For details on user_settings_file_info, please consult Building Packages.
• Purpose: Defines one or more user settings files or directories used by the packaged software.
• Required: No
• Default: ""

Shell Functions

The following shell functions will be invoked by HaikuPorter to execute the corresponding build stage. If a recipe doesn't provide a definition for one of these functions, the corresponding build stage will be empty, i.e. nothing will happen.

PATCH()

purpose: Apply algorithmic patches to the port's sources. Usually, sources are patched by providing a patchset, but sometimes it is just more convenient to apply the patches programatically, which can be done in this function. Generic example:

PATCH()
{
	find . -name '*.py' -exec sed -i -e 's|/usr/bin/env|/bin/env|g' {} \;
}

BUILD()

purpose: Execute the build stage for the current port. For a port based on autotools, this usually involves invocation of configure and make. Generic example:

BUILD()
{
	libtoolize --force --copy --install
	runConfigure ./configure
	make $jobArgs
}

INSTALL()

purpose: Collect the build results into one or more subfolders of the /packaging directory (one for each resulting package). Generic example:

INSTALL()
{
	make install
	strip $binDir/*
}

TEST()

purpose: Run any tests on the build results. Generic example:

TEST()
{
	make check
}

Examples

A simple example (using an outdated style for DESCRIPTION)

This is the build recipe for gawk, which is rather generic. It provides two commands (one of which is just a symlink to the other) and it just requires Haiku for execution.

SUMMARY="A pattern scanning and processing language"
DESCRIPTION="
	If you are like many computer users, you would frequently like to make
	changes in various text files wherever certain patterns appear, or
	extract data from parts of certain lines while discarding the rest. To
	write a program to do this in a language such as C or Pascal is a
	time-consuming inconvenience that may take many lines of code. The job
	is easy with awk, especially the GNU implementation: gawk.

	The awk utility interprets a special-purpose programming language that
	makes it possible to handle simple data-reformatting jobs with just a
	few lines of code.
	"
HOMEPAGE="http://www.gnu.org/software/coreutils"
SOURCE_URI="http://ftp.gnu.org/gnu/gawk/gawk-3.1.8.tar.bz2"
CHECKSUM_SHA256="5dbc7b2c4c328711337c2aacd09a122c7313122262e3ff034590f014067412b4"
LICENSE="GNU GPL v3"
COPYRIGHT="1983-2010 Free Software Foundation, Inc."
REVISION="2"
ARCHITECTURES="x86_gcc2 ?x86"

PROVIDES="
	gawk = $portVersion compat >= 3
	cmd:awk = $portVersion compat >= 3
	cmd:gawk = $portVersion compat >= 3
	"
REQUIRES="
	haiku
	"
BUILD_REQUIRES="
	"
BUILD_PREREQUIRES="
	haiku_devel
	cmd:gcc
	cmd:ld
	cmd:libtoolize
	cmd:make
	cmd:sed
	"

SOURCE_DIR="$portVersionedName"

BUILD()
{
	libtoolize --force --copy --install
	./configure $configureDirArgs
	make
}

INSTALL()
{
	make install
}

TEST()
{
	make check
}

A simple example (using the recommended style for DESCRIPTION)

SUMMARY="Prints out location of specified executables that are in your PATH"
DESCRIPTION="GNU 'which' is an utility that is used to find which executable \
(or alias or shell function) is executed when entered on the shell prompt."
HOMEPAGE="http://carlo17.home.xs4all.nl/which/"
COPYRIGHT="Free Software Foundation"
LICENSE="GNU GPL v2"
REVISION="4"
SOURCE_URI="https://ftp.gnu.org/gnu/which/which-$portVersion.tar.gz"
CHECKSUM_SHA256="f4a245b94124b377d8b49646bf421f9155d36aa7614b6ebf83705d3ffc76eaad"
PATCHES="which-$portVersion.patch"

ARCHITECTURES="x86_gcc2 x86 x86_64 arm"

PROVIDES="
	which = $portVersion
	cmd:which = $portVersion
	"
REQUIRES="
	haiku
	"

BUILD_REQUIRES="
	haiku_devel
	"
BUILD_PREREQUIRES="
	cmd:awk
	cmd:gcc
	cmd:grep
	cmd:make
	cmd:sed
	"

defineDebugInfoPackage which \
	$binDir/which

BUILD()
{
	runConfigure ./configure --disable-dependency-tracking
	make $jobArgs
}

INSTALL()
{
	make install
}

A simple example (using the recommended style for a multi-line COPYRIGHT)

SUMMARY="POSIX-compliant implementation of /bin/sh"
DESCRIPTION="Dash is a POSIX-compliant implementation of /bin/sh that aims to \
be as small as possible. It does this without sacrificing speed where \
possible. In fact, it is significantly faster than bash (the GNU Bourne-Again \
Shell) for most tasks."
HOMEPAGE="http://gondor.apana.org/~herbert/dash/"
COPYRIGHT="1989-1994 The Regents of the University of California
	1997 Christos Zoulas
	1997-2005 Herbert Xu"
LICENSE="GNU GPL v3"
REVISION="3"
SOURCE_URI="http://gondor.apana.org/~herbert/dash/files/dash-$portVersion.tar.gz"
CHECKSUM_SHA256="ae89fa9f1145b7748cf0740e1df04cd52fdf8a285da4911dd0f04983efba4e39"

ARCHITECTURES="!x86_gcc2 x86 x86_64"

PROVIDES="
	dash = $portVersion
	cmd:dash = $portVersion
	"
REQUIRES="
	haiku
	lib:libncursesw
	lib:libreadline
	"

BUILD_REQUIRES="
	haiku_devel
	"
BUILD_PREREQUIRES="
	cmd:awk
	cmd:gcc
	cmd:make
	"

BUILD()
{
	runConfigure ./configure
	make $jobArgs LIBS=-lbsd
}

INSTALL()
{
	make install
}

An advanced example (using an outdated style for DESCRIPTION)

This is the build recipe for git, which depends on a number of other packages at both build- and runtime. Additionally, git provides a number of general sibling packages.

SUMMARY="Fast, scalable, distributed revision control system"
DESCRIPTION="
	Git is a free and open source distributed version control system designed
	to handle everything from small to very large projects with speed and
	efficiency.

	Git is easy to learn and has a tiny footprint with lightning fast
	performance. It outclasses SCM tools like Subversion, CVS, Perforce,
	and ClearCase with features like cheap local branching, convenient
	staging areas, and multiple workflows.
	"
HOMEPAGE="http://git-scm.com/"
LICENSE="GNU GPL v2"
COPYRIGHT="2005-2012 Git Authors (see git web site for list)"

SOURCE_URI="http://git-core.googlecode.com/files/git-1.7.10.2.tar.gz"
CHECKSUM_SHA256="e9e50d0d382183a9327d39334eb65db92852208e1438aab2a9bf8d06ef17b653"
SOURCE_DIR="$portVersionedName"
PATCHES="git-1.7.10.2.patch"

SOURCE_URI_2="http://git-core.googlecode.com/files/git-manpages-1.7.10.2.tar.gz"
CHECKSUM_SHA256_2="c9340fad1f521f3782abca4839d66bfee237f3e931856413561cf1b55fc9d550"

SOURCE_URI_3="http://git-core.googlecode.com/files/git-htmldocs-1.7.10.2.tar.gz"
CHECKSUM_SHA256_3="7f5eb11cf3dd5abb4705fb91f52c78ff4265b2e2eb15948cef311b3e04896d1c"

REVISION="2"

ARCHITECTURES="x86_gcc2 ?x86"

PROVIDES="
	git = $portVersion compat >= 1.7
	cmd:git = $portVersion compat >= 1.7
	cmd:git_receive_pack = $portVersion compat >= 1.7
	cmd:git_shell = $portVersion compat >= 1.7
	cmd:git_upload_archive = $portVersion compat >= 1.7
	cmd:git_upload_pack = $portVersion compat >= 1.7
	"
PROVIDES_arch="
	git_arch = $portVersion compat >= 1.7
	cmd:git_archimport = $portVersion compat >= 1.7
	"
PROVIDES_cvs="
	git_cvs = $portVersion compat >= 1.7
	cmd:git_cvsserver = $portVersion compat >= 1.7
	"
PROVIDES_daemon="
	git_daemon = $portVersion compat >= 1.7
	cmd:git_daemon = $portVersion compat >= 1.7
	"
PROVIDES_email="
	git_email = $portVersion compat >= 1.7
	cmd:git_send_email = $portVersion compat >= 1.7
	"
PROVIDES_source="
	git_source = $portVersion compat >= 1.7
	"
PROVIDES_svn="
	git_svn = $portVersion compat >= 1.7
	cmd:git_svn = $portVersion compat >= 1.7
	"

REQUIRES="
	haiku
	curl
	expat
	man
	openssl
	perl
	python
	zlib
	cmd:nano
	"
REQUIRES_arch="
	haiku
	git == $portVersion
	"
REQUIRES_cvs="
	haiku
	git == $portVersion
	"
REQUIRES_daemon="
	haiku
	git == $portVersion
	"
REQUIRES_email="
	haiku
	git == $portVersion
	"
REQUIRES_svn="
	haiku
	git == $portVersion
	"

BUILD_REQUIRES="
	$REQUIRES
	cmd:gcc
	cmd:ld
	cmd:make
	cmd:sed
	cmd:tar
	"
BUILD_PREREQUIRES="
	haiku_devel
	"

BUILD()
{
	make
}

INSTALL()
{
	make strip
	make install

	# replace copies of git binaries with symlinks
	cd $prefix/bin
	for program in git*; do
		ln -sfn "../lib/git-core/$program" "$program"
	done

	# copy manpages
	mkdir -p $manDir
	cp -rd $sourceDir2/* $manDir/

	# copy html documentation
	htmlDir=$docDir/html
	mkdir -p $htmlDir
	cp -rd $sourceDir3/*.html $htmlDir/
	rm $htmlDir/git-gui.html

	# copy asciidoc documentation for which there isn't any corresponding html
	asciidocDir=$docDir/asciidoc
	mkdir -p $asciidocDir
	for f in $sourceDir3/*.txt; do
		html=$sourceDir3/$(basename $f .txt).html
		if ! [ -e $html ]; then
			cp -d $f $asciidocDir/
		fi
	done

	packageEntries arch \
		documentation/packages/git/html/git-archimport.html \
		documentation/man/man1/git-archimport.1 \
		lib/git-core/git-archimport

	packageEntries cvs \
		bin/git-cvsserver \
		documentation/packages/git/html/git-cvsexportcommit.html \
		documentation/packages/git/html/git-cvsimport.html \
		documentation/packages/git/html/git-cvsserver.html \
		documentation/man/man1/git-cvsexportcommit.1 \
		documentation/man/man1/git-cvsimport.1 \
		documentation/man/man1/git-cvsserver.1 \
		documentation/man/man7/gitcvs-migration.7 \
		lib/git-core/git-cvsexportcommit \
		lib/git-core/git-cvsimport \
		lib/git-core/git-cvsserver

	packageEntries daemon \
		documentation/packages/git/html/git-credential-cache--daemon.html \
		documentation/packages/git/html/git-credential-cache.html \
		documentation/packages/git/html/git-daemon.html \
		documentation/man/man1/git-credential-cache--daemon.1 \
		documentation/man/man1/git-credential-cache.1 \
		documentation/man/man1/git-daemon.1 \
		lib/git-core/git-credential-cache--daemon \
		lib/git-core/git-credential-cache \
		lib/git-core/git-daemon

	packageEntries email \
		documentation/packages/git/html/git-send-email.html \
		documentation/man/man1/git-send-email.1 \
		lib/git-core/git-send-email

	packageEntries svn \
		documentation/packages/git/html/git-svn.html \
		documentation/man/man1/git-svn.1 \
		lib/git-core/git-svn
}

Useful links

• Few tips for creating correct recipe