Common package options¶
The following outlines common configuration options available for packages.
LIBFOO_INSTALL_TYPE
¶
Defines the installation type of this package. A package may be designed to be built and installed for just the target area, the stage area, both or maybe in the host directory. The following options are available for the installation type:
Type |
Description |
---|---|
|
The host directory. |
|
The images directory. |
|
The staging area. |
|
Both the staging an target area. |
|
The target area. |
The default installation type is target
.
LIBFOO_INSTALL_TYPE = 'target'
See also LIBFOO_HOST_PROVIDES
.
LIBFOO_LICENSE
¶
A string or list of strings outlining the license information for a package. Outlining the license of a package is recommended. It is recommended to use SPDX registered licenses.
LIBFOO_LICENSE = ['GPL-2.0-only', 'MIT']
or
LIBFOO_LICENSE = 'GPL-2.0-or-later WITH Bison-exception-2.2'
or
LIBFOO_LICENSE = 'LicenseRef-MyCompanyLicense'
See also LIBFOO_LICENSE_FILES
.
LIBFOO_LICENSE_FILES
¶
A string or list of strings identifying the license files found inside the
package sources which typically would match up to the defined LICENSE
entries (respectively).
LIBFOO_LICENSE_FILES = [
'LICENSE.GPLv2',
'LICENSE.MIT',
]
or
LIBFOO_LICENSE_FILES = 'LICENSE'
See also LIBFOO_LICENSE
.
LIBFOO_NEEDS
¶
Bemerkung
The option replaces the legacy
LIBFOO_DEPENDENCIES
option.
Added in version 1.3.
List of package dependencies a given project has. If a project depends on
another package, the package name should be listed in this option. This ensures
releng-tool will process packages in the proper order. The following shows an
example package libfoo
being dependent on liba
and libb
being
processed first:
LIBFOO_NEEDS = [
'liba',
'libb',
]
LIBFOO_SITE
¶
The site where package sources/assets can be found. The site can be a URL of an archive, or describe a source control URL such as Git or SVN. The following outline a series of supported site definitions:
Geändert in Version 0.10: Support added for rsync+
.
Geändert in Version 0.17: Support added for perforce+
.
Geändert in Version 1.4: Support added for brz+
.
Type |
Prefix/Postfix |
---|---|
Breezy |
|
Bazaar |
|
CVS |
|
Git |
|
Mercurial |
|
Perforce |
|
rsync |
|
SCP |
|
SVN |
|
URL |
|
Examples include:
LIBFOO_SITE = 'https://example.com/libfoo.git'
LIBFOO_SITE = 'cvs+:pserver:anonymous@cvs.example.com:/var/lib/cvsroot mymodule'
LIBFOO_SITE = 'svn+https://svn.example.com/repos/libfoo/c/branches/libfoo-1.2'
LIBFOO_SITE = 'https://www.example.com/files/libfoo.tar.gz'
LIBFOO_SITE = {
DEFAULT_SITE: 'https://pkgs.example.com/releases/libfoo-${LIBFOO_VERSION}.tar.gz',
'<mode>': 'https://git.example.com/libfoo.git',
}
A developer can also use LIBFOO_VCS_TYPE
to
explicitly define the version control system type without the need for a
prefix hint. The use of a dictionary value is only useful when operating in
development mode. For more information on each
type’s formatting, see site definitions.
Using a specific type will create a dependency for a project that the
respective host tool is installed on the host system. For example, if a
Git site is set, the host system will need to have git
installed on the
system.
If no site is defined for a package, it will be considered a virtual package (i.e. has no content). If applicable, loaded extensions may provide support for custom site protocols.
Specifying a local site value with local
will automatically
configure a VCS-type of local
.
See also LIBFOO_VCS_TYPE
.
LIBFOO_TYPE
¶
Geändert in Version 0.13: Support added for make
.
Geändert in Version 0.16: Support added for meson
.
Geändert in Version 1.3: Support added for cargo
.
The package type. The default package type is a (Python) script-based package. releng-tool also provides a series of helper package types for common frameworks. The following outline a series of supported type definitions:
Type |
Value |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For example:
LIBFOO_TYPE = 'script'
If no type is defined for a package, it will be considered a script-based package. If applicable, loaded extensions may provide support for custom types.
Using a specific type will create a dependency for a project that the
respective host tool is installed on the host system. For example, if a
CMake type is set, the host system will need to have cmake
installed on
the system.
LIBFOO_VERSION
¶
The version of the package. Typically the version value should be formatted in a semantic versioning style, but it is up to the developer to decide the best version value to use for a package. It is important to note that the version value is used to determine build output folder names, cache files and more.
LIBFOO_VERSION = '1.0.0'
For some VCS types, the version value will be used to acquire a specific
revision of sources. If for some case the desired version value cannot be
gracefully defined (e.g. a version value libfoo-v1.0
will produce output
directories such as libfoo-libfoo-v1.0
),
LIBFOO_REVISION
can be used.
See also LIBFOO_DEVMODE_REVISION
and
LIBFOO_REVISION
.