From 1a825210d8e629129a00ae6fc7ad7f359eb76132 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Wed, 30 Jul 2014 08:40:59 +0300 Subject: dev-manual: Updates to the creating partitioned images section. Fixes [YOCTO #6511] Added a new example to this section that shows how to package up binaries so that you can add them to an image. (From yocto-docs rev: e52acc444c8f142d0469d7274fb936b5242306ec) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- .../dev-manual/dev-manual-common-tasks.xml | 91 ++++++++++++++++++++++ 1 file changed, 91 insertions(+) (limited to 'documentation') diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml index d33cef6d89..be95c0f405 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/documentation/dev-manual/dev-manual-common-tasks.xml @@ -2668,6 +2668,7 @@ Using an Autotooled package Using a Makefile-based package Splitting an application into multiple packages + Adding binaries to an image @@ -2868,6 +2869,96 @@ does not include the above listed files. + +
+ Packaging Externally Produced Binaries + + + Sometimes, you need to add pre-compiled binaries to an + image. + For example, suppose that binaries for proprietary code + exist, which are created by a particular division of a + company. + Your part of the company needs to use those binaries as + part of an image that you are building using the + OpenEmbedded build system. + Since you only have the binaries and not the source code, + you cannot use a typical recipe that expects to fetch the + source specified in + SRC_URI + and then compile it. + + + + One method is to package the binaries and then install them + as part of the image. + Generally, it is not a good idea to package binaries + since, among other things, it can hinder the ability to + reproduce builds and could lead to compatibility problems + with ABI in the future. + However, sometimes you have no choice. + + + + The easiest solution is to create a recipe that uses + the + bin_package + class and to be sure that you are using default locations + for build artifacts. + In most cases, the bin_package class + handles "skipping" the configure and compile steps as well + as sets things up to grab packages from the appropriate + area. + In particular, this class sets noexec + on both the + do_configure + and + do_compile + tasks, sets + FILES_${PN} to "/" so that it picks + up all files, and sets up a + do_install + task, which effectively copies all files from + ${S} to ${D}. + For more information on these variables, see the + FILES, + PN, + S, + and + D + variables in the Yocto Project Reference Manual's variable + glossary. + + + + If you can't use the bin_package + class, you need to be sure you are doing the following: + + Create a recipe where the + do_configure and + do_compile tasks do nothing: + + do_configure[noexec] = "1" + do_compile[noexec] = "1" + + Alternatively, you can make these tasks an empty + function. + + make sure your + do_install task installs the + binaries appropriately. + + Ensure that you set up + FILES (usually + FILES_${PN}) to point to the + files you have installed, which of course depends + on where you have installed them and whether + those files are in different locations than the + defaults. + + + +
-- cgit v1.2.3-54-g00ecf