From: Scott Rifenbark Date: Wed, 7 Aug 2013 08:18:17 +0000 (+0300) Subject: ref-manual: Changes to the externalsrc.bbclass reference section. X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=d066247ade2d86897bc4c42ba2c34c549286d06b;p=thirdparty%2Fopenembedded%2Fopenembedded-core-contrib.git ref-manual: Changes to the externalsrc.bbclass reference section. Updated this to not contain usage information, which has been moved to the dev-manual. I diff'ed out this commit and there are some changes that resulted from accidental deletion and restoration of a large amount of text. (From yocto-docs rev: fdefcfd77811d2cfe65d51b70f3bc69018f3de81) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml index d80fd77f9f9..e3d7544c023 100644 --- a/documentation/ref-manual/ref-classes.xml +++ b/documentation/ref-manual/ref-classes.xml @@ -179,7 +179,7 @@ Pkg-config - <filename>pkgconfig.bbclass</filename> - pkg-config provides a standard way to get + pkg-config provides a standard way to get header and library information. This class aims to smooth integration of pkg-config into libraries that use it. @@ -198,7 +198,7 @@ Many software licenses require that source code and other materials be - released with the binaries. + released with the binaries. To help with that task, the following classes are provided: archive-original-sources.bbclass @@ -515,47 +515,47 @@ since pkg-config itself adds the correct sysroot prefix when the files are accessed. textrel: - Checks for ELF binaries that contain relocations in their - .text sections, which can result in a + Checks for ELF binaries that contain relocations in their + .text sections, which can result in a performance impact at runtime. pkgvarcheck: - Checks through the variables - RDEPENDS, - RRECOMMENDS, + Checks through the variables + RDEPENDS, + RRECOMMENDS, RSUGGESTS, RCONFLICTS, RPROVIDES, - RREPLACES, + RREPLACES, FILES, ALLOW_EMPTY, - pkg_preinst, - pkg_postinst, + pkg_preinst, + pkg_postinst, pkg_prerm - and pkg_postrm, and reports if there are + and pkg_postrm, and reports if there are variable sets that are not package-specific. Using these variables without a package suffix is bad practice, and might unnecessarily complicate dependencies of other packages within the same recipe or have other unintended consequences. xorg-driver-abi: - Checks that all packages containing Xorg drivers have ABI + Checks that all packages containing Xorg drivers have ABI dependencies. - The xserver-xorg recipe provides driver + The xserver-xorg recipe provides driver ABI names. - All drivers should depend on the ABI versions that they have - been built against. - Driver recipes that include + All drivers should depend on the ABI versions that they have + been built against. + Driver recipes that include xorg-driver-input.inc - or xorg-driver-video.inc will + or xorg-driver-video.inc will automatically get these versions. - Consequently, you should only need to explicitly add + Consequently, you should only need to explicitly add dependencies to binary driver recipes. libexec: - Checks if a package contains files in + Checks if a package contains files in /usr/libexec. - This check is not performed if the - libexecdir variable has been set + This check is not performed if the + libexecdir variable has been set explicitly to /usr/libexec. staticdev: @@ -575,21 +575,21 @@ - You can use the WARN_QA and - ERROR_QA variables to control the behavior of - these checks at the global level (i.e. in your custom distro + You can use the WARN_QA and + ERROR_QA variables to control the behavior of + these checks at the global level (i.e. in your custom distro configuration). - However, to skip one or more checks in recipes, you should use - INSANE_SKIP. - For example, to skip the check for symbolic link - .so files in the main package of a recipe, + However, to skip one or more checks in recipes, you should use + INSANE_SKIP. + For example, to skip the check for symbolic link + .so files in the main package of a recipe, add the following to the recipe. You need to realize that the package name override, in this example ${PN}, must be used: INSANE_SKIP_${PN} += "dev-so" - Please keep in mind that the QA checks exist in order to detect real + Please keep in mind that the QA checks exist in order to detect real or potential problems in the packaged output. So exercise caution when disabling these checks. @@ -599,28 +599,28 @@ Removing Work Files During the Build - <filename>rm_work.bbclass</filename> - The OpenEmbedded build system can use a substantial amount of disk + The OpenEmbedded build system can use a substantial amount of disk space during the build process. - A portion of this space is the work files under the - ${TMPDIR}/work directory for each recipe. - Once the build system generates the packages for a recipe, the work + A portion of this space is the work files under the + ${TMPDIR}/work directory for each recipe. + Once the build system generates the packages for a recipe, the work files for that recipe are no longer needed. However, by default, the build system preserves these files for inspection and possible debugging purposes. - If you would rather have these files deleted to save disk space + If you would rather have these files deleted to save disk space as the build progresses, you can enable rm_work by adding the following to your local.conf file, - which is found in the + which is found in the Build Directory. INHERIT += "rm_work" - If you are modifying and building source code out of the work directory - for a recipe, enabling rm_work will potentially - result in your changes to the source being lost. + If you are modifying and building source code out of the work directory + for a recipe, enabling rm_work will potentially + result in your changes to the source being lost. To exclude some recipes from having their work directories deleted by - rm_work, you can add the names of the recipe or - recipes you are working on to the RM_WORK_EXCLUDE + rm_work, you can add the names of the recipe or + recipes you are working on to the RM_WORK_EXCLUDE variable, which can also be set in your local.conf file. Here is an example: @@ -677,28 +677,37 @@
- Using External Source - <filename>externalsrc.bbclass</filename> + <filename>externalsrc.bbclass</filename> - You can use this class to build software from source code that is external to the - OpenEmbedded build system. - In other words, your source code resides in an external tree outside of the Yocto Project. - Building software from an external source tree means that the normal fetch, unpack, and - patch process is not used. + You can use this class to build software from source code that is + external to the OpenEmbedded build system. + Building software from an external source tree means that the build + system's normal fetch, unpack, and patch process is not used. - To use the class, you need to define the - S variable to point to the directory that contains the source files. - You also need to have your recipe inherit the externalsrc.bbclass class. + By default, the OpenEmbedded build system uses the + S and + B variables to + locate unpacked recipe source code and to build it, respectively. + When your recipe inherits externalsrc.bbclass, + you use the + EXTERNALSRC + and + EXTERNALSRC_BUILD + variables to ultimately define S and + B. - This class expects the source code to support recipe builds that use the - B variable to point to the directory in - which the OpenEmbedded build system places the generated objects built from the recipes. - By default, the B directory is set to the following, which is separate from the - Source Directory (S): + By default, this class expects the source code to support recipe builds + that use the B + variable to point to the directory in which the OpenEmbedded build + system places the generated objects built from the recipes. + By default, the B directory is set to the + following, which is separate from the source directory + (S): ${WORKDIR}/${BPN}/{PV}/ @@ -706,36 +715,17 @@ WORKDIR, BPN, PV, - S, and - B for more information. - You can build object files in the external tree by setting the - B variable equal to "${S}". - However, this practice does not work well if you use the source for more than one variant - (i.e., "natives" such as quilt-native, - or "crosses" such as gcc-cross). - So, be sure there are no "native", "cross", or "multilib" variants of the recipe. - - - - If you do want to build different variants of a recipe, you can use the - BBCLASSEXTEND variable. - When you do, the B variable must support the - recipe's ability to build variants in different working directories. - Most Autotools-based recipes support separating these directories. - The OpenEmbedded build system defaults to using separate directories for gcc - and some kernel recipes. - Alternatively, you can make sure that separate recipes exist that each - use the BBCLASSEXTEND variable to build each variant. - The separate recipes can inherit a single target recipe. - - - - For information on how to use this class, see the - "Building - Software from an External Source" section in the Yocto Project Development Manual. + For more information on + externalsrc.bbclass, see the comments in + meta/classes/externalsrc.bbclass in the + Source Directory. + For information on how to use externalsrc.bbclass, + see the + "Building Software from an External Source" + section in the Yocto Project Development Manual.