diff options
Diffstat (limited to 'documentation/ref-manual/ref-structure.rst')
| -rw-r--r-- | documentation/ref-manual/ref-structure.rst | 890 |
1 files changed, 0 insertions, 890 deletions
diff --git a/documentation/ref-manual/ref-structure.rst b/documentation/ref-manual/ref-structure.rst deleted file mode 100644 index 48a443331b..0000000000 --- a/documentation/ref-manual/ref-structure.rst +++ /dev/null @@ -1,890 +0,0 @@ -.. SPDX-License-Identifier: CC-BY-2.0-UK - -************************** -Source Directory Structure -************************** - -The :term:`Source Directory` consists of numerous files, -directories and subdirectories; understanding their locations and -contents is key to using the Yocto Project effectively. This chapter -describes the Source Directory and gives information about those files -and directories. - -For information on how to establish a local Source Directory on your -development system, see the -":ref:`dev-manual/dev-manual-start:locating yocto project source files`" -section in the Yocto Project Development Tasks Manual. - -.. note:: - - The OpenEmbedded build system does not support file or directory - names that contain spaces. Be sure that the Source Directory you use - does not contain these types of names. - -.. _structure-core: - -Top-Level Core Components -========================= - -This section describes the top-level components of the :term:`Source Directory`. - -.. _structure-core-bitbake: - -``bitbake/`` ------------- - -This directory includes a copy of BitBake for ease of use. The copy -usually matches the current stable BitBake release from the BitBake -project. BitBake, a :term:`Metadata` interpreter, reads the -Yocto Project Metadata and runs the tasks defined by that data. Failures -are usually caused by errors in your Metadata and not from BitBake -itself; consequently, most users do not need to worry about BitBake. - -When you run the ``bitbake`` command, the main BitBake executable (which -resides in the ``bitbake/bin/`` directory) starts. Sourcing the -environment setup script (i.e. :ref:`structure-core-script`) places -the ``scripts/`` and ``bitbake/bin/`` directories (in that order) into -the shell's ``PATH`` environment variable. - -For more information on BitBake, see the :doc:`BitBake User Manual -<bitbake:index>`. - -.. _structure-core-build: - -``build/`` ----------- - -This directory contains user configuration files and the output -generated by the OpenEmbedded build system in its standard configuration -where the source tree is combined with the output. The :term:`Build Directory` -is created initially when you ``source`` -the OpenEmbedded build environment setup script (i.e. -:ref:`structure-core-script`). - -It is also possible to place output and configuration files in a -directory separate from the :term:`Source Directory` by -providing a directory name when you ``source`` the setup script. For -information on separating output from your local Source Directory files -(commonly described as an "out of tree" build), see the -":ref:`structure-core-script`" section. - -.. _handbook: - -``documentation/`` ------------------- - -This directory holds the source for the Yocto Project documentation as -well as templates and tools that allow you to generate PDF and HTML -versions of the manuals. Each manual is contained in its own sub-folder; -for example, the files for this reference manual reside in the -``ref-manual/`` directory. - -.. _structure-core-meta: - -``meta/`` ---------- - -This directory contains the minimal, underlying OpenEmbedded-Core -metadata. The directory holds recipes, common classes, and machine -configuration for strictly emulated targets (``qemux86``, ``qemuarm``, -and so forth.) - -.. _structure-core-meta-poky: - -``meta-poky/`` --------------- - -Designed above the ``meta/`` content, this directory adds just enough -metadata to define the Poky reference distribution. - -.. _structure-core-meta-yocto-bsp: - -``meta-yocto-bsp/`` -------------------- - -This directory contains the Yocto Project reference hardware Board -Support Packages (BSPs). For more information on BSPs, see the -:doc:`../bsp-guide/bsp-guide`. - -.. _structure-meta-selftest: - -``meta-selftest/`` ------------------- - -This directory adds additional recipes and append files used by the -OpenEmbedded selftests to verify the behavior of the build system. You -do not have to add this layer to your ``bblayers.conf`` file unless you -want to run the selftests. - -.. _structure-meta-skeleton: - -``meta-skeleton/`` ------------------- - -This directory contains template recipes for BSP and kernel development. - -.. _structure-core-scripts: - -``scripts/`` ------------- - -This directory contains various integration scripts that implement extra -functionality in the Yocto Project environment (e.g. QEMU scripts). The -:ref:`structure-core-script` script prepends this directory to the -shell's ``PATH`` environment variable. - -The ``scripts`` directory has useful scripts that assist in contributing -back to the Yocto Project, such as ``create-pull-request`` and -``send-pull-request``. - -.. _structure-core-script: - -``oe-init-build-env`` ---------------------- - -This script sets up the OpenEmbedded build environment. Running this -script with the ``source`` command in a shell makes changes to ``PATH`` -and sets other core BitBake variables based on the current working -directory. You need to run an environment setup script before running -BitBake commands. The script uses other scripts within the ``scripts`` -directory to do the bulk of the work. - -When you run this script, your Yocto Project environment is set up, a -:term:`Build Directory` is created, your working -directory becomes the Build Directory, and you are presented with some -simple suggestions as to what to do next, including a list of some -possible targets to build. Here is an example: -:: - - $ source oe-init-build-env - - ### Shell environment set up for builds. ### - - You can now run 'bitbake <target>' - - Common targets are: - core-image-minimal - core-image-sato - meta-toolchain - meta-ide-support - - You can also run generated qemu images with a command like 'runqemu qemux86-64' - -The default output of the ``oe-init-build-env`` script is from the -``conf-notes.txt`` file, which is found in the ``meta-poky`` directory -within the :term:`Source Directory`. If you design a -custom distribution, you can include your own version of this -configuration file to mention the targets defined by your distribution. -See the -":ref:`dev-manual/dev-manual-common-tasks:creating a custom template configuration directory`" -section in the Yocto Project Development Tasks Manual for more -information. - -By default, running this script without a Build Directory argument -creates the ``build/`` directory in your current working directory. If -you provide a Build Directory argument when you ``source`` the script, -you direct the OpenEmbedded build system to create a Build Directory of -your choice. For example, the following command creates a Build -Directory named ``mybuilds/`` that is outside of the :term:`Source Directory`: -:: - - $ source OE_INIT_FILE ~/mybuilds - -The OpenEmbedded build system uses the template configuration files, which -are found by default in the ``meta-poky/conf/`` directory in the Source -Directory. See the -":ref:`dev-manual/dev-manual-common-tasks:creating a custom template configuration directory`" -section in the Yocto Project Development Tasks Manual for more -information. - -.. note:: - - The OpenEmbedded build system does not support file or directory - names that contain spaces. If you attempt to run the - OE_INIT_FILE - script from a Source Directory that contains spaces in either the - filenames or directory names, the script returns an error indicating - no such file or directory. Be sure to use a Source Directory free of - names containing spaces. - -.. _structure-basic-top-level: - -``LICENSE, README, and README.hardware`` ----------------------------------------- - -These files are standard top-level files. - -.. _structure-build: - -The Build Directory - ``build/`` -================================ - -The OpenEmbedded build system creates the :term:`Build Directory` -when you run the build environment setup -script :ref:`structure-core-script`. If you do not give the Build -Directory a specific name when you run the setup script, the name -defaults to ``build/``. - -For subsequent parsing and processing, the name of the Build directory -is available via the :term:`TOPDIR` variable. - -.. _structure-build-buildhistory: - -``build/buildhistory/`` ------------------------ - -The OpenEmbedded build system creates this directory when you enable -build history via the ``buildhistory`` class file. The directory -organizes build information into image, packages, and SDK -subdirectories. For information on the build history feature, see the -":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`" -section in the Yocto Project Development Tasks Manual. - -.. _structure-build-conf-local.conf: - -``build/conf/local.conf`` -------------------------- - -This configuration file contains all the local user configurations for -your build environment. The ``local.conf`` file contains documentation -on the various configuration options. Any variable set here overrides -any variable set elsewhere within the environment unless that variable -is hard-coded within a file (e.g. by using '=' instead of '?='). Some -variables are hard-coded for various reasons but such variables are -relatively rare. - -At a minimum, you would normally edit this file to select the target -``MACHINE``, which package types you wish to use -(:term:`PACKAGE_CLASSES`), and the location from -which you want to access downloaded files (``DL_DIR``). - -If ``local.conf`` is not present when you start the build, the -OpenEmbedded build system creates it from ``local.conf.sample`` when you -``source`` the top-level build environment setup script -:ref:`structure-core-script`. - -The source ``local.conf.sample`` file used depends on the -``$TEMPLATECONF`` script variable, which defaults to ``meta-poky/conf/`` -when you are building from the Yocto Project development environment, -and to ``meta/conf/`` when you are building from the OpenEmbedded-Core -environment. Because the script variable points to the source of the -``local.conf.sample`` file, this implies that you can configure your -build environment from any layer by setting the variable in the -top-level build environment setup script as follows: -:: - - TEMPLATECONF=your_layer/conf - -Once the build process gets the sample -file, it uses ``sed`` to substitute final -``${``\ :term:`OEROOT`\ ``}`` values for all -``##OEROOT##`` values. - -.. note:: - - You can see how the - TEMPLATECONF - variable is used by looking at the - scripts/oe-setup-builddir - script in the - Source Directory - . You can find the Yocto Project version of the - local.conf.sample - file in the - meta-poky/conf - directory. - -.. _structure-build-conf-bblayers.conf: - -``build/conf/bblayers.conf`` ----------------------------- - -This configuration file defines -:ref:`layers <dev-manual/dev-manual-common-tasks:understanding and creating layers>`, -which are directory trees, traversed (or walked) by BitBake. The -``bblayers.conf`` file uses the :term:`BBLAYERS` -variable to list the layers BitBake tries to find. - -If ``bblayers.conf`` is not present when you start the build, the -OpenEmbedded build system creates it from ``bblayers.conf.sample`` when -you ``source`` the top-level build environment setup script (i.e. -:ref:`structure-core-script`). - -As with the ``local.conf`` file, the source ``bblayers.conf.sample`` -file used depends on the ``$TEMPLATECONF`` script variable, which -defaults to ``meta-poky/conf/`` when you are building from the Yocto -Project development environment, and to ``meta/conf/`` when you are -building from the OpenEmbedded-Core environment. Because the script -variable points to the source of the ``bblayers.conf.sample`` file, this -implies that you can base your build from any layer by setting the -variable in the top-level build environment setup script as follows: -:: - - TEMPLATECONF=your_layer/conf - -Once the build process gets the sample file, it uses ``sed`` to substitute final -``${``\ :term:`OEROOT`\ ``}`` values for all ``##OEROOT##`` values. - -.. note:: - - You can see how the - TEMPLATECONF - variable - scripts/oe-setup-builddir - script in the - Source Directory - . You can find the Yocto Project version of the - bblayers.conf.sample - file in the - meta-poky/conf/ - directory. - -.. _structure-build-conf-sanity_info: - -``build/cache/sanity_info`` ---------------------------- - -This file indicates the state of the sanity checks and is created during -the build. - -.. _structure-build-downloads: - -``build/downloads/`` --------------------- - -This directory contains downloaded upstream source tarballs. You can -reuse the directory for multiple builds or move the directory to another -location. You can control the location of this directory through the -``DL_DIR`` variable. - -.. _structure-build-sstate-cache: - -``build/sstate-cache/`` ------------------------ - -This directory contains the shared state cache. You can reuse the -directory for multiple builds or move the directory to another location. -You can control the location of this directory through the -``SSTATE_DIR`` variable. - -.. _structure-build-tmp: - -``build/tmp/`` --------------- - -The OpenEmbedded build system creates and uses this directory for all -the build system's output. The :term:`TMPDIR` variable -points to this directory. - -BitBake creates this directory if it does not exist. As a last resort, -to clean up a build and start it from scratch (other than the -downloads), you can remove everything in the ``tmp`` directory or get -rid of the directory completely. If you do, you should also completely -remove the ``build/sstate-cache`` directory. - -.. _structure-build-tmp-buildstats: - -``build/tmp/buildstats/`` -------------------------- - -This directory stores the build statistics. - -.. _structure-build-tmp-cache: - -``build/tmp/cache/`` --------------------- - -When BitBake parses the metadata (recipes and configuration files), it -caches the results in ``build/tmp/cache/`` to speed up future builds. -The results are stored on a per-machine basis. - -During subsequent builds, BitBake checks each recipe (together with, for -example, any files included or appended to it) to see if they have been -modified. Changes can be detected, for example, through file -modification time (mtime) changes and hashing of file contents. If no -changes to the file are detected, then the parsed result stored in the -cache is reused. If the file has changed, it is reparsed. - -.. _structure-build-tmp-deploy: - -``build/tmp/deploy/`` ---------------------- - -This directory contains any "end result" output from the OpenEmbedded -build process. The :term:`DEPLOY_DIR` variable points -to this directory. For more detail on the contents of the ``deploy`` -directory, see the -":ref:`images-dev-environment`" and -":ref:`sdk-dev-environment`" sections in the Yocto -Project Overview and Concepts Manual. - -.. _structure-build-tmp-deploy-deb: - -``build/tmp/deploy/deb/`` -------------------------- - -This directory receives any ``.deb`` packages produced by the build -process. The packages are sorted into feeds for different architecture -types. - -.. _structure-build-tmp-deploy-rpm: - -``build/tmp/deploy/rpm/`` -------------------------- - -This directory receives any ``.rpm`` packages produced by the build -process. The packages are sorted into feeds for different architecture -types. - -.. _structure-build-tmp-deploy-ipk: - -``build/tmp/deploy/ipk/`` -------------------------- - -This directory receives ``.ipk`` packages produced by the build process. - -.. _structure-build-tmp-deploy-licenses: - -``build/tmp/deploy/licenses/`` ------------------------------- - -This directory receives package licensing information. For example, the -directory contains sub-directories for ``bash``, ``busybox``, and -``glibc`` (among others) that in turn contain appropriate ``COPYING`` -license files with other licensing information. For information on -licensing, see the -":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`" -section in the Yocto Project Development Tasks Manual. - -.. _structure-build-tmp-deploy-images: - -``build/tmp/deploy/images/`` ----------------------------- - -This directory is populated with the basic output objects of the build -(think of them as the "generated artifacts" of the build process), -including things like the boot loader image, kernel, root filesystem and -more. If you want to flash the resulting image from a build onto a -device, look here for the necessary components. - -Be careful when deleting files in this directory. You can safely delete -old images from this directory (e.g. ``core-image-*``). However, the -kernel (``*zImage*``, ``*uImage*``, etc.), bootloader and other -supplementary files might be deployed here prior to building an image. -Because these files are not directly produced from the image, if you -delete them they will not be automatically re-created when you build the -image again. - -If you do accidentally delete files here, you will need to force them to -be re-created. In order to do that, you will need to know the target -that produced them. For example, these commands rebuild and re-create -the kernel files: -:: - - $ bitbake -c clean virtual/kernel - $ bitbake virtual/kernel - -.. _structure-build-tmp-deploy-sdk: - -``build/tmp/deploy/sdk/`` -------------------------- - -The OpenEmbedded build system creates this directory to hold toolchain -installer scripts which, when executed, install the sysroot that matches -your target hardware. You can find out more about these installers in -the ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" -section in the Yocto Project Application Development and the Extensible -Software Development Kit (eSDK) manual. - -.. _structure-build-tmp-sstate-control: - -``build/tmp/sstate-control/`` ------------------------------ - -The OpenEmbedded build system uses this directory for the shared state -manifest files. The shared state code uses these files to record the -files installed by each sstate task so that the files can be removed -when cleaning the recipe or when a newer version is about to be -installed. The build system also uses the manifests to detect and -produce a warning when files from one task are overwriting those from -another. - -.. _structure-build-tmp-sysroots-components: - -``build/tmp/sysroots-components/`` ----------------------------------- - -This directory is the location of the sysroot contents that the task -:ref:`ref-tasks-prepare_recipe_sysroot` -links or copies into the recipe-specific sysroot for each recipe listed -in :term:`DEPENDS`. Population of this directory is -handled through shared state, while the path is specified by the -:term:`COMPONENTS_DIR` variable. Apart from a few -unusual circumstances, handling of the ``sysroots-components`` directory -should be automatic, and recipes should not directly reference -``build/tmp/sysroots-components``. - -.. _structure-build-tmp-sysroots: - -``build/tmp/sysroots/`` ------------------------ - -Previous versions of the OpenEmbedded build system used to create a -global shared sysroot per machine along with a native sysroot. Beginning -with the DISTRO version of the Yocto Project, sysroots exist in -recipe-specific :term:`WORKDIR` directories. Thus, the -``build/tmp/sysroots/`` directory is unused. - -.. note:: - - The - build/tmp/sysroots/ - directory can still be populated using the - bitbake build-sysroots - command and can be used for compatibility in some cases. However, in - general it is not recommended to populate this directory. Individual - recipe-specific sysroots should be used. - -.. _structure-build-tmp-stamps: - -``build/tmp/stamps/`` ---------------------- - -This directory holds information that BitBake uses for accounting -purposes to track what tasks have run and when they have run. The -directory is sub-divided by architecture, package name, and version. -Following is an example: -stamps/all-poky-linux/distcc-config/1.0-r0.do_build-2fdd....2do Although -the files in the directory are empty of data, BitBake uses the filenames -and timestamps for tracking purposes. - -For information on how BitBake uses stamp files to determine if a task -should be rerun, see the -":ref:`overview-manual/overview-manual-concepts:stamp files and the rerunning of tasks`" -section in the Yocto Project Overview and Concepts Manual. - -.. _structure-build-tmp-log: - -``build/tmp/log/`` ------------------- - -This directory contains general logs that are not otherwise placed using -the package's ``WORKDIR``. Examples of logs are the output from the -``do_check_pkg`` or ``do_distro_check`` tasks. Running a build does not -necessarily mean this directory is created. - -.. _structure-build-tmp-work: - -``build/tmp/work/`` -------------------- - -This directory contains architecture-specific work sub-directories for -packages built by BitBake. All tasks execute from the appropriate work -directory. For example, the source for a particular package is unpacked, -patched, configured and compiled all within its own work directory. -Within the work directory, organization is based on the package group -and version for which the source is being compiled as defined by the -:term:`WORKDIR`. - -It is worth considering the structure of a typical work directory. As an -example, consider ``linux-yocto-kernel-3.0`` on the machine ``qemux86`` -built within the Yocto Project. For this package, a work directory of -``tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....>``, referred -to as the ``WORKDIR``, is created. Within this directory, the source is -unpacked to ``linux-qemux86-standard-build`` and then patched by Quilt. -(See the ":ref:`using-a-quilt-workflow`" section in -the Yocto Project Development Tasks Manual for more information.) Within -the ``linux-qemux86-standard-build`` directory, standard Quilt -directories ``linux-3.0/patches`` and ``linux-3.0/.pc`` are created, and -standard Quilt commands can be used. - -There are other directories generated within ``WORKDIR``. The most -important directory is ``WORKDIR/temp/``, which has log files for each -task (``log.do_*.pid``) and contains the scripts BitBake runs for each -task (``run.do_*.pid``). The ``WORKDIR/image/`` directory is where "make -install" places its output that is then split into sub-packages within -``WORKDIR/packages-split/``. - -.. _structure-build-tmp-work-tunearch-recipename-version: - -``build/tmp/work/tunearch/recipename/version/`` ------------------------------------------------ - -The recipe work directory - ``${WORKDIR}``. - -As described earlier in the -"```build/tmp/sysroots/`` <#structure-build-tmp-sysroots>`__" section, -beginning with the DISTRO release of the Yocto Project, the OpenEmbedded -build system builds each recipe in its own work directory (i.e. -:term:`WORKDIR`). The path to the work directory is -constructed using the architecture of the given build (e.g. -:term:`TUNE_PKGARCH`, -:term:`MACHINE_ARCH`, or "allarch"), the recipe -name, and the version of the recipe (i.e. -:term:`PE`\ ``:``\ :term:`PV`\ ``-``\ :term:`PR`). - -A number of key subdirectories exist within each recipe work directory: - -- ``${WORKDIR}/temp``: Contains the log files of each task executed for - this recipe, the "run" files for each executed task, which contain - the code run, and a ``log.task_order`` file, which lists the order in - which tasks were executed. - -- ``${WORKDIR}/image``: Contains the output of the - :ref:`ref-tasks-install` task, which corresponds to - the ``${``\ :term:`D`\ ``}`` variable in that task. - -- ``${WORKDIR}/pseudo``: Contains the pseudo database and log for any - tasks executed under pseudo for the recipe. - -- ``${WORKDIR}/sysroot-destdir``: Contains the output of the - :ref:`ref-tasks-populate_sysroot` task. - -- ``${WORKDIR}/package``: Contains the output of the - :ref:`ref-tasks-package` task before the output is - split into individual packages. - -- ``${WORKDIR}/packages-split``: Contains the output of the - ``do_package`` task after the output has been split into individual - packages. Subdirectories exist for each individual package created by - the recipe. - -- ``${WORKDIR}/recipe-sysroot``: A directory populated with the target - dependencies of the recipe. This directory looks like the target - filesystem and contains libraries that the recipe might need to link - against (e.g. the C library). - -- ``${WORKDIR}/recipe-sysroot-native``: A directory populated with the - native dependencies of the recipe. This directory contains the tools - the recipe needs to build (e.g. the compiler, Autoconf, libtool, and - so forth). - -- ``${WORKDIR}/build``: This subdirectory applies only to recipes that - support builds where the source is separate from the build artifacts. - The OpenEmbedded build system uses this directory as a separate build - directory (i.e. ``${``\ :term:`B`\ ``}``). - -.. _structure-build-work-shared: - -``build/tmp/work-shared/`` --------------------------- - -For efficiency, the OpenEmbedded build system creates and uses this -directory to hold recipes that share a work directory with other -recipes. In practice, this is only used for ``gcc`` and its variants -(e.g. ``gcc-cross``, ``libgcc``, ``gcc-runtime``, and so forth). - -.. _structure-meta: - -The Metadata - ``meta/`` -======================== - -As mentioned previously, :term:`Metadata` is the core of the -Yocto Project. Metadata has several important subdivisions: - -.. _structure-meta-classes: - -``meta/classes/`` ------------------ - -This directory contains the ``*.bbclass`` files. Class files are used to -abstract common code so it can be reused by multiple packages. Every -package inherits the ``base.bbclass`` file. Examples of other important -classes are ``autotools.bbclass``, which in theory allows any -Autotool-enabled package to work with the Yocto Project with minimal -effort. Another example is ``kernel.bbclass`` that contains common code -and functions for working with the Linux kernel. Functions like image -generation or packaging also have their specific class files such as -``image.bbclass``, ``rootfs_*.bbclass`` and ``package*.bbclass``. - -For reference information on classes, see the -":ref:`ref-manual/ref-classes:Classes`" chapter. - -.. _structure-meta-conf: - -``meta/conf/`` --------------- - -This directory contains the core set of configuration files that start -from ``bitbake.conf`` and from which all other configuration files are -included. See the include statements at the end of the ``bitbake.conf`` -file and you will note that even ``local.conf`` is loaded from there. -While ``bitbake.conf`` sets up the defaults, you can often override -these by using the (``local.conf``) file, machine file or the -distribution configuration file. - -.. _structure-meta-conf-machine: - -``meta/conf/machine/`` ----------------------- - -This directory contains all the machine configuration files. If you set -``MACHINE = "qemux86"``, the OpenEmbedded build system looks for a -``qemux86.conf`` file in this directory. The ``include`` directory -contains various data common to multiple machines. If you want to add -support for a new machine to the Yocto Project, look in this directory. - -.. _structure-meta-conf-distro: - -``meta/conf/distro/`` ---------------------- - -The contents of this directory controls any distribution-specific -configurations. For the Yocto Project, the ``defaultsetup.conf`` is the -main file here. This directory includes the versions and the ``SRCDATE`` -definitions for applications that are configured here. An example of an -alternative configuration might be ``poky-bleeding.conf``. Although this -file mainly inherits its configuration from Poky. - -.. _structure-meta-conf-machine-sdk: - -``meta/conf/machine-sdk/`` --------------------------- - -The OpenEmbedded build system searches this directory for configuration -files that correspond to the value of -:term:`SDKMACHINE`. By default, 32-bit and 64-bit x86 -files ship with the Yocto Project that support some SDK hosts. However, -it is possible to extend that support to other SDK hosts by adding -additional configuration files in this subdirectory within another -layer. - -.. _structure-meta-files: - -``meta/files/`` ---------------- - -This directory contains common license files and several text files used -by the build system. The text files contain minimal device information -and lists of files and directories with known permissions. - -.. _structure-meta-lib: - -``meta/lib/`` -------------- - -This directory contains OpenEmbedded Python library code used during the -build process. - -.. _structure-meta-recipes-bsp: - -``meta/recipes-bsp/`` ---------------------- - -This directory contains anything linking to specific hardware or -hardware configuration information such as "u-boot" and "grub". - -.. _structure-meta-recipes-connectivity: - -``meta/recipes-connectivity/`` ------------------------------- - -This directory contains libraries and applications related to -communication with other devices. - -.. _structure-meta-recipes-core: - -``meta/recipes-core/`` ----------------------- - -This directory contains what is needed to build a basic working Linux -image including commonly used dependencies. - -.. _structure-meta-recipes-devtools: - -``meta/recipes-devtools/`` --------------------------- - -This directory contains tools that are primarily used by the build -system. The tools, however, can also be used on targets. - -.. _structure-meta-recipes-extended: - -``meta/recipes-extended/`` --------------------------- - -This directory contains non-essential applications that add features -compared to the alternatives in core. You might need this directory for -full tool functionality or for Linux Standard Base (LSB) compliance. - -.. _structure-meta-recipes-gnome: - -``meta/recipes-gnome/`` ------------------------ - -This directory contains all things related to the GTK+ application -framework. - -.. _structure-meta-recipes-graphics: - -``meta/recipes-graphics/`` --------------------------- - -This directory contains X and other graphically related system -libraries. - -.. _structure-meta-recipes-kernel: - -``meta/recipes-kernel/`` ------------------------- - -This directory contains the kernel and generic applications and -libraries that have strong kernel dependencies. - -.. _structure-meta-recipes-lsb4: - -``meta/recipes-lsb4/`` ----------------------- - -This directory contains recipes specifically added to support the Linux -Standard Base (LSB) version 4.x. - -.. _structure-meta-recipes-multimedia: - -``meta/recipes-multimedia/`` ----------------------------- - -This directory contains codecs and support utilities for audio, images -and video. - -.. _structure-meta-recipes-rt: - -``meta/recipes-rt/`` --------------------- - -This directory contains package and image recipes for using and testing -the ``PREEMPT_RT`` kernel. - -.. _structure-meta-recipes-sato: - -``meta/recipes-sato/`` ----------------------- - -This directory contains the Sato demo/reference UI/UX and its associated -applications and configuration data. - -.. _structure-meta-recipes-support: - -``meta/recipes-support/`` -------------------------- - -This directory contains recipes used by other recipes, but that are not -directly included in images (i.e. dependencies of other recipes). - -.. _structure-meta-site: - -``meta/site/`` --------------- - -This directory contains a list of cached results for various -architectures. Because certain "autoconf" test results cannot be -determined when cross-compiling due to the tests not able to run on a -live system, the information in this directory is passed to "autoconf" -for the various architectures. - -.. _structure-meta-recipes-txt: - -``meta/recipes.txt`` --------------------- - -This file is a description of the contents of ``recipes-*``. |