diff options
Diffstat (limited to 'yocto-poky/documentation/ref-manual/ref-classes.xml')
| -rw-r--r-- | yocto-poky/documentation/ref-manual/ref-classes.xml | 294 |
1 files changed, 138 insertions, 156 deletions
diff --git a/yocto-poky/documentation/ref-manual/ref-classes.xml b/yocto-poky/documentation/ref-manual/ref-classes.xml index b2941b8bf..e919bd7eb 100644 --- a/yocto-poky/documentation/ref-manual/ref-classes.xml +++ b/yocto-poky/documentation/ref-manual/ref-classes.xml @@ -128,8 +128,7 @@ <para> By default, the <filename>autotools*</filename> classes use out-of-tree builds (i.e. - <filename>autotools.bbclass</filename> and - <filename>autotools_stage.bbclass</filename>). + <filename>autotools.bbclass</filename>). (<link linkend='var-B'><filename>B</filename></link> <filename>!=</filename> <link linkend='var-S'><filename>S</filename></link>). </para> @@ -139,8 +138,7 @@ using out-of-tree builds, you should have the recipe inherit the <filename>autotools-brokensep</filename> class. The <filename>autotools-brokensep</filename> class behaves the same - as the <filename>autotools</filename> and - <filename>autotools_stage</filename> classes but builds with + as the <filename>autotools</filename> class but builds with <link linkend='var-B'><filename>B</filename></link> == <link linkend='var-S'><filename>S</filename></link>. This method is useful when out-of-tree build support is either not @@ -201,6 +199,15 @@ </para> </section> +<section id='ref-classes-bash-completion'> + <title><filename>bash-completion.bbclass</filename></title> + + <para> + Sets up packaging and dependencies appropriate for recipes that + build software that includes bash-completion data. + </para> +</section> + <section id='ref-classes-bin-package'> <title><filename>bin_package.bbclass</filename></title> @@ -319,64 +326,6 @@ </para> </section> -<section id='ref-classes-boot-directdisk'> - <title><filename>boot-directdisk.bbclass</filename></title> - - <para> - The <filename>boot-directdisk</filename> class - creates an image that can be placed directly onto a hard disk using - <filename>dd</filename> and then booted. - The image uses SYSLINUX. - </para> - - <para> - The end result is a 512 boot sector populated with a - Master Boot Record (MBR) and partition table followed by an MSDOS - FAT16 partition containing SYSLINUX and a Linux kernel completed by - the <filename>ext2</filename> and <filename>ext3</filename> - root filesystems. - </para> -</section> - -<section id='ref-classes-bootimg'> - <title><filename>bootimg.bbclass</filename></title> - - <para> - The <filename>bootimg</filename> class creates a bootable - image using SYSLINUX, your kernel, and an optional initial RAM disk - (<filename>initrd</filename>). - </para> - - <para> - When you use this class, two things happen: - <itemizedlist> - <listitem><para> - A <filename>.hddimg</filename> file is created. - This file is an MSDOS filesystem that contains SYSLINUX, - a kernel, an <filename>initrd</filename>, and a root filesystem - image. - All three of these can be written to hard drives directly and - also booted on a USB flash disks using <filename>dd</filename>. - </para></listitem> - <listitem><para> - A CD <filename>.iso</filename> image is created. - When this file is booted, the <filename>initrd</filename> - boots and processes the label selected in SYSLINUX. - Actions based on the label are then performed (e.g. installing - to a hard drive).</para></listitem> - </itemizedlist> - </para> - - <para> - The <filename>bootimg</filename> class supports the - <link linkend='var-INITRD'><filename>INITRD</filename></link>, - <link linkend='var-NOISO'><filename>NOISO</filename></link>, - <link linkend='var-NOHDD'><filename>NOHDD</filename></link>, and - <link linkend='var-ROOTFS'><filename>ROOTFS</filename></link> - variables. - </para> -</section> - <section id='ref-classes-bugzilla'> <title><filename>bugzilla.bbclass</filename></title> @@ -714,7 +663,9 @@ provides for automatic checking for upstream recipe updates. The class creates a comma-separated value (CSV) spreadsheet that contains information about the recipes. - The information provides the <filename>do_distrodata</filename> and + The information provides the + <link linkend='ref-tasks-distrodata'><filename>do_distrodata</filename></link> + and <filename>do_distro_check</filename> tasks, which do upstream checking and also verify if a package is used in multiple major distributions. </para> @@ -728,6 +679,13 @@ INHERIT+= "distrodata" </literallayout> </para> + + <para> + The <filename>distrodata</filename> class also provides the + <link linkend='ref-tasks-checkpkg'><filename>do_checkpkg</filename></link> + task, which can be used against a simple recipe or against an + image to get all its recipe information. + </para> </section> <section id='ref-classes-distutils'> @@ -999,6 +957,28 @@ </para> </section> +<section id='ref-classes-gobject-introspection'> + <title><filename>gobject-introspection.bbclass</filename></title> + + <para> + Provides support for recipes building software that + supports GObject introspection. + This functionality is only enabled if the + "gobject-introspection-data" feature is in + <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link> + as well as "qemu-usermode" being in + <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>. + <note> + This functionality is backfilled by default and, + if not applicable, should be disabled through + <link linkend='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename></link> + or + <link linkend='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'><filename>MACHINE_FEATURES_BACKFILL_CONSIDERED</filename></link>, + respectively. + </note> + </para> +</section> + <section id='ref-classes-grub-efi'> <title><filename>grub-efi.bbclass</filename></title> @@ -1146,8 +1126,8 @@ <title><filename>gzipnative.bbclass</filename></title> <para> - The <filename>gzipnative</filename> - class enables the use of native versions of <filename>gzip</filename> + The <filename>gzipnative</filename> class enables the use of + different native versions of <filename>gzip</filename> and <filename>pigz</filename> rather than the versions of these tools from the build host. </para> @@ -2284,6 +2264,29 @@ </para> </section> +<section id='ref-classes-nopackages'> + <title><filename>nopackages.bbclass</filename></title> + + <para> + Disables packaging tasks for those recipes and classes where + packaging is not needed. + </para> +</section> + +<section id='ref-classes-npm'> + <title><filename>npm.bbclass</filename></title> + + <para> + Provides support for building Node.js software fetched using the npm + package manager. + <note> + Currently, recipes inheriting this class must use the + <filename>npm://</filename> fetcher to have dependencies fetched + and packaged automatically. + </note> + </para> +</section> + <section id='ref-classes-oelint'> <title><filename>oelint.bbclass</filename></title> @@ -2558,22 +2561,6 @@ </para> </section> -<section id='ref-classes-packageinfo'> - <title><filename>packageinfo.bbclass</filename></title> - - <para> - The <filename>packageinfo</filename> class - gives a BitBake user interface the ability to retrieve information - about output packages from the <filename>pkgdata</filename> files. - </para> - - <para> - This class is enabled automatically when using the - <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> - user interface. - </para> -</section> - <section id='ref-classes-patch'> <title><filename>patch.bbclass</filename></title> @@ -2654,8 +2641,8 @@ toolchain using the <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link> task, see the - "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>" - section in the Yocto Project Application Developer's Guide. + "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>" + section in the Yocto Project Software Development Kit (SDK) Developer's Guide. </para> </section> @@ -2734,8 +2721,9 @@ cross-development toolchain using the <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link> task, see the - "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>" - section in the Yocto Project Application Developer's Guide. + "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>" + section in the Yocto Project Software Development Kit (SDK) Developer's + Guide. </para> </section> @@ -2869,66 +2857,6 @@ </para> </section> -<section id='ref-classes-qmake*'> - <title><filename>qmake*.bbclass</filename></title> - - <para> - The <filename>qmake*</filename> classes support recipes that - need to build software that uses Qt's <filename>qmake</filename> - build system and are comprised of the following: - <itemizedlist> - <listitem><para><emphasis><filename>qmake_base</filename>:</emphasis> - Provides base functionality for all versions of - <filename>qmake</filename>.</para></listitem> - <listitem><para><emphasis><filename>qmake2</filename>:</emphasis> - Extends base functionality for <filename>qmake</filename> 2.x as - used by Qt 4.x.</para></listitem> - </itemizedlist> - </para> - - <para> - If you need to set any configuration variables or pass any options to - <filename>qmake</filename>, you can add these to the - <link linkend='var-EXTRA_QMAKEVARS_PRE'><filename>EXTRA_QMAKEVARS_PRE</filename></link> - or - <link linkend='var-EXTRA_QMAKEVARS_POST'><filename>EXTRA_QMAKEVARS_POST</filename></link> - variables, depending on whether the arguments need to be before or - after the <filename>.pro</filename> file list on the command line, - respectively. - </para> - - <para> - By default, all <filename>.pro</filename> files are built. - If you want to specify your own subset of <filename>.pro</filename> - files to be built, specify them in the - <link linkend='var-QMAKE_PROFILES'><filename>QMAKE_PROFILES</filename></link> - variable. - </para> -</section> - -<section id='ref-classes-qt4*'> - <title><filename>qt4*.bbclass</filename></title> - - <para> - The <filename>qt4*</filename> classes support recipes that need to - build software that uses the Qt development framework version 4.x - and consist of the following: - <itemizedlist> - <listitem><para><emphasis><filename>qt4e</filename>:</emphasis> - Supports building against Qt/Embedded, which uses the - framebuffer for graphical output.</para></listitem> - <listitem><para><emphasis><filename>qt4x11</filename>:</emphasis> - Supports building against Qt/X11.</para></listitem> - </itemizedlist> - </para> - - <para> - The classes inherit the - <link linkend='ref-classes-qmake*'><filename>qmake2</filename></link> - class. - </para> -</section> - <section id='ref-classes-recipe_sanity'> <title><filename>recipe_sanity.bbclass</filename></title> @@ -2958,6 +2886,33 @@ </para> </section> +<section id='ref-classes-remove-libtool'> + <title><filename>remove-libtool.bbclass</filename></title> + + <para> + The <filename>remove-libtool</filename> class adds a post function + to the + <link linkend='ref-tasks-install'><filename>do_install</filename></link> + task to remove all <filename>.la</filename> files installed by + <filename>libtool</filename>. + Removing these files results in them being absent from both the + sysroot and target packages. + </para> + + <para> + If a recipe needs the <filename>.la</filename> files to be installed, + then the recipe can override the removal by setting + <filename>REMOVE_LIBTOOL_LA</filename> to "0" as follows: + <literallayout class='monospaced'> + REMOVE_LIBTOOL_LA = "0" + </literallayout> + <note> + The <filename>remove-libtool</filename> class is not enabled by + default. + </note> + </para> +</section> + <section id='ref-classes-report-error'> <title><filename>report-error.bbclass</filename></title> @@ -3026,6 +2981,10 @@ the root filesystem for an image and consist of the following classes: <itemizedlist> <listitem><para> + The <filename>rootfs-postcommands</filename> class, which + defines filesystem post-processing functions for image recipes. + </para></listitem> + <listitem><para> The <filename>rootfs_deb</filename> class, which supports creation of root filesystems for images built using <filename>.deb</filename> packages.</para></listitem> @@ -3225,10 +3184,10 @@ <title><filename>staging.bbclass</filename></title> <para> - The <filename>staging</filename> class provides support for staging - files into the sysroot during the + The <filename>staging</filename> class provides the <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link> - task. + task, which stages files into the sysroot to make them available to + other recipes at build time. The class is enabled by default because it is inherited by the <link linkend='ref-classes-base'><filename>base</filename></link> class. @@ -3398,6 +3357,20 @@ </para> </section> +<section id='ref-classes-testsdk'> + <title><filename>testsdk.bbclass</filename></title> + + <para> + This class supports running automated tests against + software development kits (SDKs). + The <filename>testsdk</filename> class runs tests on an SDK when + called using the following: + <literallayout class='monospaced'> + $ bitbake -c testsdk image + </literallayout> + </para> +</section> + <section id='ref-classes-texinfo'> <title><filename>texinfo.bbclass</filename></title> @@ -3498,14 +3471,23 @@ <title><filename>uninative.bbclass</filename></title> <para> - Provides a means of reusing <filename>native/cross</filename> over - multiple distros. - <note> - Currently, the method used by the <filename>uninative</filename> - class is experimental. - </note> - For more information, see the commit message - <ulink url='http://cgit.openembedded.org/openembedded-core/commit/?id=e66c96ae9c7ba21ebd04a4807390f0031238a85a'>here</ulink>. + Attempts to isolate the build system from the host + distribution's C library in order to make re-use of native shared state + artifacts across different host distributions practical. + With this class enabled, a tarball containing a pre-built C library + is downloaded at the start of the build. + In the Poky reference distribution this is enabled by default + through + <filename>meta/conf/distro/include/yocto-uninative.inc</filename>. + Other distributions that do not derive from poky can also + "<filename>require conf/distro/include/yocto-uninative.inc</filename>" + to use this. + Alternatively if you prefer, you can build the uninative-tarball recipe + yourself, publish the resulting tarball (e.g. via HTTP) and set + <filename>UNINATIVE_URL</filename> and + <filename>UNINATIVE_CHECKSUM</filename> appropriately. + For an example, see the + <filename>meta/conf/distro/include/yocto-uninative.inc</filename>. </para> </section> |