The first thing your recipe must do is specify how to fetch
the source files.
Fetching is controlled mainly through the
SRC_URI
variable.
Your recipe must have a SRC_URI
variable
that points to where the source is located.
For a graphical representation of source locations, see the
"Sources"
section in the Yocto Project Reference Manual.
The
do_fetch
task uses the prefix of each entry in the
SRC_URI
variable value to determine which
fetcher to use to get your source files.
It is the SRC_URI
variable that triggers
the fetcher.
The
do_patch
task uses the variable after source is fetched to apply
patches.
The OpenEmbedded build system uses
FILESOVERRIDES
for scanning directory locations for local files in
SRC_URI
.
The SRC_URI
variable in your recipe must
define each unique location for your source files.
It is good practice to not hard-code pathnames in an URL used
in SRC_URI
.
Rather than hard-code these paths, use
${
PV
}
,
which causes the fetch process to use the version specified in
the recipe filename.
Specifying the version in this manner means that upgrading the
recipe to a future version is as simple as renaming the recipe
to match the new version.
Here is a simple example from the
meta/recipes-devtools/cdrtools/cdrtools-native_3.01a20.bb
recipe where the source comes from a single tarball.
Notice the use of the
PV
variable:
SRC_URI = "ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-${PV}.tar.bz2"
Files mentioned in SRC_URI
whose names end
in a typical archive extension (e.g. .tar
,
.tar.gz
, .tar.bz2
,
.zip
, and so forth), are automatically
extracted during the
do_unpack
task.
For another example that specifies these types of files, see
the
"Autotooled Package"
section.
Another way of specifying source is from an SCM.
For Git repositories, you must specify
SRCREV
and you should specify
PV
to include the revision with
SRCPV
.
Here is an example from the recipe
meta/recipes-kernel/blktrace/blktrace_git.bb
:
SRCREV = "d6918c8832793b4205ed3bfede78c2f915c23385" PR = "r6" PV = "1.0.5+git${SRCPV}" SRC_URI = "git://git.kernel.dk/blktrace.git \ file://ldflags.patch"
If your SRC_URI
statement includes
URLs pointing to individual files fetched from a remote server
other than a version control system, BitBake attempts to
verify the files against checksums defined in your recipe to
ensure they have not been tampered with or otherwise modified
since the recipe was written.
Two checksums are used:
SRC_URI[md5sum]
and
SRC_URI[sha256sum]
.
If your SRC_URI
variable points to
more than a single URL (excluding SCM URLs), you need to
provide the md5
and
sha256
checksums for each URL.
For these cases, you provide a name for each URL as part of
the SRC_URI
and then reference that name
in the subsequent checksum statements.
Here is an example:
SRC_URI = "${DEBIAN_MIRROR}/main/a/apmd/apmd_3.2.2.orig.tar.gz;name=tarball \ ${DEBIAN_MIRROR}/main/a/apmd/apmd_${PV}.diff.gz;name=patch SRC_URI[tarball.md5sum] = "b1e6309e8331e0f4e6efd311c2d97fa8" SRC_URI[tarball.sha256sum] = "7f7d9f60b7766b852881d40b8ff91d8e39fccb0d1d913102a5c75a2dbb52332d" SRC_URI[patch.md5sum] = "57e1b689264ea80f78353519eece0c92" SRC_URI[patch.sha256sum] = "7905ff96be93d725544d0040e425c42f9c05580db3c272f11cff75b9aa89d430"
Proper values for md5
and
sha256
checksums might be available
with other signatures on the download page for the upstream
source (e.g. md5
,
sha1
, sha256
,
GPG
, and so forth).
Because the OpenEmbedded build system only deals with
sha256sum
and md5sum
,
you should verify all the signatures you find by hand.
If no SRC_URI
checksums are specified
when you attempt to build the recipe, or you provide an
incorrect checksum, the build will produce an error for each
missing or incorrect checksum.
As part of the error message, the build system provides
the checksum string corresponding to the fetched file.
Once you have the correct checksums, you can copy and paste
them into your recipe and then run the build again to continue.
This final example is a bit more complicated and is from the
meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.20.bb
recipe.
The example's SRC_URI
statement identifies
multiple files as the source files for the recipe: a tarball, a
patch file, a desktop file, and an icon.
SRC_URI = "http://dist.schmorp.de/rxvt-unicode/Attic/rxvt-unicode-${PV}.tar.bz2 \ file://xwc.patch \ file://rxvt.desktop \ file://rxvt.png"
When you specify local files using the
file://
URI protocol, the build system
fetches files from the local machine.
The path is relative to the
FILESPATH
variable and searches specific directories in a certain order:
${
BP
}
,
${
BPN
}
,
and files
.
The directories are assumed to be subdirectories of the
directory in which the recipe or append file resides.
For another example that specifies these types of files, see the
"Single .c File Package (Hello World!)"
section.
The previous example also specifies a patch file.
Patch files are files whose names usually end in
.patch
or .diff
but
can end with compressed suffixes such as
diff.gz
and
patch.bz2
, for example.
The build system automatically applies patches as described
in the
"Patching Code" section.