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 what
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.01a17.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"
To find these checksums, you can comment the statements out and then attempt to build the software. The build will produce an error for each missing checksum and as part of the error message provide the correct checksum string. Once you have the correct checksums, simply copy them into your recipe for a subsequent build.
This final example is a bit more complicated and is from the
meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.19.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:
${
BPN
}
,
${
BP
}
,
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 end in
.patch
or .diff
.
The build system automatically applies patches as described
in the
"Patching Code" section.