5.3.6. Fetching Code

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.