From 2eaf7e6e7524ec2a1eeca35b41f123fdee7e120b Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Thu, 16 Oct 2014 16:31:19 -0700 Subject: ref-manual: Scrubbed for variable (user) input. Throughout the manual I had been using angled bracket sets to denote user-supplied input. This is confusing and better shown by using the tags. I scrubbed all the chapters and replaced as needed. Some other minor formatting changes were caught and fixed during the scrub as well. (From yocto-docs rev: 9a668574dd18828a750cfa2e8c28e1f089a19609) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/ref-manual/closer-look.xml | 32 +++--- documentation/ref-manual/faq.xml | 2 +- documentation/ref-manual/introduction.xml | 8 +- documentation/ref-manual/migration.xml | 25 ++--- documentation/ref-manual/ref-classes.xml | 24 ++--- documentation/ref-manual/ref-features.xml | 2 +- documentation/ref-manual/ref-images.xml | 46 ++++----- documentation/ref-manual/ref-qa-checks.xml | 2 +- documentation/ref-manual/ref-structure.xml | 6 +- documentation/ref-manual/ref-tasks.xml | 10 +- documentation/ref-manual/ref-variables.xml | 132 +++++++++++++------------ documentation/ref-manual/technical-details.xml | 11 ++- documentation/ref-manual/usingpoky.xml | 26 ++--- 13 files changed, 166 insertions(+), 160 deletions(-) (limited to 'documentation') diff --git a/documentation/ref-manual/closer-look.xml b/documentation/ref-manual/closer-look.xml index f0ed967228..c0c0d619a4 100644 --- a/documentation/ref-manual/closer-look.xml +++ b/documentation/ref-manual/closer-look.xml @@ -255,7 +255,7 @@ When you launch your build with the - bitbake <target> command, BitBake + bitbake target command, BitBake sorts out the configurations to ultimately define your build environment. @@ -351,7 +351,7 @@ Best practices dictate that you isolate these types of configurations into their own layer. Settings you provide in - conf/distro/<distro>.conf override + conf/distro/distro.conf override similar settings that BitBake finds in your conf/local.conf file in the Build @@ -375,7 +375,7 @@ This area holds configuration files for the layer (conf/layer.conf), the distribution - (conf/distro/<distro>.conf), + (conf/distro/distro.conf), and any distribution-wide include files. recipes-*: @@ -408,7 +408,7 @@ The BSP Layer's configuration directory contains configuration files for the machine - (conf/machine/<machine>.conf) and, + (conf/machine/machine.conf) and, of course, the layer (conf/layer.conf). @@ -1145,7 +1145,7 @@ Images are written out to the Build Directory - inside the tmp/deploy/images/<machine>/ + inside the tmp/deploy/images/machine/ folder as shown in the figure. This folder contains any files expected to be loaded on the target device. @@ -1157,43 +1157,43 @@ variable points to the appropriate directory containing images for the current configuration. - <kernel-image>: + kernel-image: A kernel binary file. The KERNEL_IMAGETYPE variable setting determines the naming scheme for the kernel image file. Depending on that variable, the file could begin with a variety of naming strings. - The deploy/images/<machine> + The deploy/images/machine directory can contain multiple image files for the machine. - <root-filesystem-image>: + root-filesystem-image: Root filesystems for the target device (e.g. *.ext3 or *.bz2 files). The IMAGE_FSTYPES variable setting determines the root filesystem image type. - The deploy/images/<machine> + The deploy/images/machine directory can contain multiple root filesystems for the machine. - <kernel-modules>: + kernel-modules: Tarballs that contain all the modules built for the kernel. Kernel module tarballs exist for legacy purposes and can be suppressed by setting the MODULE_TARBALL_DEPLOY variable to "0". - The deploy/images/<machine> + The deploy/images/machine directory can contain multiple kernel module tarballs for the machine. - <bootloaders>: + bootloaders: Bootloaders supporting the image, if applicable to the target machine. - The deploy/images/<machine> + The deploy/images/machine directory can contain multiple bootloaders for the machine. - <symlinks>: - The deploy/images/<machine> + symlinks: + The deploy/images/machine folder contains a symbolic link that points to the most recently built file for each machine. @@ -1280,7 +1280,7 @@ part of the SDK (i.e. the part that runs on the SDKMACHINE). When you use - bitbake -c populate_sdk <imagename> + bitbake -c populate_sdk imagename to create the SDK, a set of default packages apply. This variable allows you to add more packages. diff --git a/documentation/ref-manual/faq.xml b/documentation/ref-manual/faq.xml index 5488f8ef23..da6ce20eef 100644 --- a/documentation/ref-manual/faq.xml +++ b/documentation/ref-manual/faq.xml @@ -321,7 +321,7 @@ - What’s the difference between foo and foo-native? + What’s the difference between target and target-native? diff --git a/documentation/ref-manual/introduction.xml b/documentation/ref-manual/introduction.xml index a81f4cbe09..f0db72a461 100644 --- a/documentation/ref-manual/introduction.xml +++ b/documentation/ref-manual/introduction.xml @@ -402,14 +402,14 @@ choose the installation directory. For example, you could choose the following: - /home/your-username/buildtools + /home/your-username/buildtools Source the tools environment setup script by using a command like the following: - $ source /home/your-username/buildtools/environment-setup-i586-poky-linux + $ source /home/your-username/buildtools/environment-setup-i586-poky-linux Of course, you need to supply your installation directory and be sure to use the right file (i.e. i585 or x86-64). @@ -488,14 +488,14 @@ choose the installation directory. For example, you could choose the following: - /home/your-username/buildtools + /home/your-username/buildtools Source the tools environment setup script by using a command like the following: - $ source /home/your-username/buildtools/environment-setup-i586-poky-linux + $ source /home/your-username/buildtools/environment-setup-i586-poky-linux Of course, you need to supply your installation directory and be sure to use the right file (i.e. i585 or x86-64). diff --git a/documentation/ref-manual/migration.xml b/documentation/ref-manual/migration.xml index f8bd852ad8..0e297b582a 100644 --- a/documentation/ref-manual/migration.xml +++ b/documentation/ref-manual/migration.xml @@ -110,7 +110,7 @@ appended to the path used to access the mirror. Here is an example: - SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH" + SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH" @@ -375,10 +375,11 @@ Shared State Code: The shared state code has been optimized to avoid running unnecessary tasks. - For example, - bitbake -c rootfs some-image from - shared state no longer populates the target sysroot - since that is not necessary. + For example, the following no longer populates the target + sysroot since that is not necessary: + + $ bitbake -c rootfs some-image + Instead, the system just needs to extract the output package contents, re-create the packages, and construct the root filesystem. @@ -832,7 +833,7 @@ This directory is located under sysroots and uses a machine-specific name (i.e. - tmp/sysroots/<machine>/pkgdata). + tmp/sysroots/machine/pkgdata). @@ -1100,7 +1101,7 @@ base-files: Remove the unnecessary - media/xxx directories. + media/xxx directories. alsa-state: Provide an empty @@ -1228,7 +1229,7 @@ value against the branch. You can specify the branch using the following form: - SRC_URI = "git://server.name/repository;branch=<branchname>" + SRC_URI = "git://server.name/repository;branch=branchname" If you do not specify a branch, BitBake looks in the default "master" branch. @@ -1305,10 +1306,10 @@
- <filename>task-<taskname></filename> Overrides + <filename>task-</filename><replaceable>taskname</replaceable> Overrides - task-<taskname> overrides have been + task-taskname overrides have been adjusted so that tasks whose names contain underscores have the underscores replaced by hyphens for the override so that they now function properly. @@ -1932,8 +1933,8 @@ Package QA checks are now performed during a new - do_package_qa task rather - than being part of the + do_package_qa + task rather than being part of the do_package task. This allows more parallel execution. diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml index 0bc917c09c..ed6d059e01 100644 --- a/documentation/ref-manual/ref-classes.xml +++ b/documentation/ref-manual/ref-classes.xml @@ -1947,7 +1947,7 @@ You can create a recipe that builds tools that run natively on the host a couple different ways: - Create a myrecipe-native.bb + Create a myrecipe-native.bb that inherits the native class. If you use this method, you must order the inherit statement in the recipe after all other inherit statements so that the @@ -1988,7 +1988,7 @@ You can create a recipe that builds tools that run on the SDK machine a couple different ways: - Create a myrecipe-nativesdk.bb + Create a myrecipe-nativesdk.bb recipe that inherits the nativesdk class. If you use this method, you must order the inherit statement in the recipe after all other inherit statements so that the @@ -2915,37 +2915,37 @@ The class supports the following variables: - INITRD: + INITRD: Indicates list of filesystem images to concatenate and use as an initial RAM disk (initrd). This variable is optional. - ROOTFS: + ROOTFS: Indicates a filesystem image to include as the root filesystem. This variable is optional. - AUTO_SYSLINUXMENU: + AUTO_SYSLINUXMENU: Enables creating an automatic menu when set to "1". - LABELS: + LABELS: Lists targets for automatic configuration. - APPEND: + APPEND: Lists append string overrides for each label. - SYSLINUX_OPTS: + SYSLINUX_OPTS: Lists additional options to add to the syslinux file. Semicolon characters separate multiple options. - SYSLINUX_SPLASH: + SYSLINUX_SPLASH: Lists a background for the VGA boot menu when you are using the boot menu. - SYSLINUX_DEFAULT_CONSOLE: + SYSLINUX_DEFAULT_CONSOLE: Set to "console=ttyX" to change kernel boot default console. - SYSLINUX_SERIAL: + SYSLINUX_SERIAL: Sets an alternate serial port. Or, turns off serial when the variable is set with an empty string. - SYSLINUX_SERIAL_TTY: + SYSLINUX_SERIAL_TTY: Sets an alternate "console=tty..." kernel boot argument. diff --git a/documentation/ref-manual/ref-features.xml b/documentation/ref-manual/ref-features.xml index b6f0bdc1e2..230cabd155 100644 --- a/documentation/ref-manual/ref-features.xml +++ b/documentation/ref-manual/ref-features.xml @@ -42,7 +42,7 @@ changed based on a given feature: $ cd poky - $ git grep 'contains.*MACHINE_FEATURES.*<feature>' + $ git grep 'contains.*MACHINE_FEATURES.*feature' diff --git a/documentation/ref-manual/ref-images.xml b/documentation/ref-manual/ref-images.xml index 503595c364..d15ca5b93a 100644 --- a/documentation/ref-manual/ref-images.xml +++ b/documentation/ref-manual/ref-images.xml @@ -38,9 +38,9 @@ - Following, is a list of supported recipes: + Following is a list of supported recipes: - build-appliance-image: + build-appliance-image: An example virtual machine that contains all the pieces required to run builds using the build system as well as the build system itself. You can boot and run the image using either the @@ -49,18 +49,18 @@ For more information on this image, see the Build Appliance page on the Yocto Project website. - core-image-base: + core-image-base: A console-only image that fully supports the target device hardware. - core-image-clutter: + core-image-clutter: An image with support for the Open GL-based toolkit Clutter, which enables development of rich and animated graphical user interfaces. - core-image-directfb: + core-image-directfb: An image that uses directfb instead of X11. - core-image-full-cmdline: + core-image-full-cmdline: A console-only image with more full-featured Linux system functionality installed. - core-image-lsb: + core-image-lsb: An image that conforms to the Linux Standard Base (LSB) specification. This image requires a distribution configuration that @@ -68,7 +68,7 @@ If you build core-image-lsb without that configuration, the image will not be LSB-compliant. - core-image-lsb-dev: + core-image-lsb-dev: A core-image-lsb image that is suitable for development work using the host. The image includes headers and libraries you can use in a host development @@ -78,7 +78,7 @@ If you build core-image-lsb-dev without that configuration, the image will not be LSB-compliant. - core-image-lsb-sdk: + core-image-lsb-sdk: A core-image-lsb that includes everything in meta-toolchain but also includes development headers and libraries to form a complete standalone SDK. @@ -87,15 +87,15 @@ If you build core-image-lsb-sdk without that configuration, the image will not be LSB-compliant. This image is suitable for development using the target. - core-image-minimal: + core-image-minimal: A small image just capable of allowing a device to boot. - core-image-minimal-dev: + core-image-minimal-dev: A core-image-minimal image suitable for development work using the host. The image includes headers and libraries you can use in a host development environment. - core-image-minimal-initramfs: + core-image-minimal-initramfs: A core-image-minimal image that has the Minimal RAM-based Initial Root Filesystem (initramfs) as part of the kernel, which allows the system to find the first “init” program more efficiently. @@ -104,38 +104,38 @@ variable for additional information helpful when working with initramfs images. - core-image-minimal-mtdutils: + core-image-minimal-mtdutils: A core-image-minimal image that has support for the Minimal MTD Utilities, which let the user interact with the MTD subsystem in the kernel to perform operations on flash devices. - core-image-rt: + core-image-rt: A core-image-minimal image plus a real-time test suite and tools appropriate for real-time use. - core-image-rt-sdk: + core-image-rt-sdk: A core-image-rt image that includes everything in meta-toolchain. The image also includes development headers and libraries to form a complete stand-alone SDK and is suitable for development using the target. - core-image-sato: + core-image-sato: An image with Sato support, a mobile environment and visual style that works well with mobile devices. The image supports X11 with a Sato theme and applications such as a terminal, editor, file manager, media player, and so forth. - core-image-sato-dev: + core-image-sato-dev: A core-image-sato image suitable for development using the host. The image includes libraries needed to build applications on the device itself, testing and profiling tools, and debug symbols. This image was formerly core-image-sdk. - core-image-sato-sdk: + core-image-sato-sdk: A core-image-sato image that includes everything in meta-toolchain. The image also includes development headers and libraries to form a complete standalone SDK and is suitable for development using the target. - core-image-testmaster: + core-image-testmaster: A "master" image designed to be used for automated runtime testing. Provides a "known good" image that is deployed to a separate partition so that you can boot into it and use it to deploy a @@ -144,21 +144,21 @@ "Performing Automated Runtime Testing" section in the Yocto Project Development Manual. - core-image-testmaster-initramfs: + core-image-testmaster-initramfs: A RAM-based Initial Root Filesystem (initramfs) image tailored for use with the core-image-testmaster image. - core-image-weston: + core-image-weston: A very basic Wayland image with a terminal. This image provides the Wayland protocol libraries and the reference Weston compositor. For more information, see the "Wayland" section. - core-image-x11: + core-image-x11: A very basic X11 image with a terminal. - qt4e-demo-image: + qt4e-demo-image: An image that launches into the demo application for the embedded (not based on X11) version of Qt. diff --git a/documentation/ref-manual/ref-qa-checks.xml b/documentation/ref-manual/ref-qa-checks.xml index 969074bf60..871cd294f6 100644 --- a/documentation/ref-manual/ref-qa-checks.xml +++ b/documentation/ref-manual/ref-qa-checks.xml @@ -727,7 +727,7 @@ can be found then it should be implemented. I can't find one at the moment. files that it should not have (e.g. a non-symlink .so file) or it might have been added manually (e.g. by adding to - RDEPENDS. + RDEPENDS). diff --git a/documentation/ref-manual/ref-structure.xml b/documentation/ref-manual/ref-structure.xml index eb1be38701..14419d3a84 100644 --- a/documentation/ref-manual/ref-structure.xml +++ b/documentation/ref-manual/ref-structure.xml @@ -315,7 +315,7 @@ commands. Following is the script syntax: - $ source oe-init-build-env-memres <port_number> <build_dir> + $ source oe-init-build-env-memres port_number build_dir The script uses other scripts within the scripts directory to do the bulk of the work. @@ -499,7 +499,7 @@ the variable in the top-level build environment setup script as follows: - TEMPLATECONF=<your_layer>/conf + TEMPLATECONF=your_layer/conf Once the build process gets the sample file, it uses sed to substitute final @@ -554,7 +554,7 @@ 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 + TEMPLATECONF=your_layer/conf Once the build process gets the sample file, it uses sed to substitute final diff --git a/documentation/ref-manual/ref-tasks.xml b/documentation/ref-manual/ref-tasks.xml index 1c8034b661..f325f0e233 100644 --- a/documentation/ref-manual/ref-tasks.xml +++ b/documentation/ref-manual/ref-tasks.xml @@ -324,7 +324,7 @@ You can run this task using BitBake as follows: - $ bitbake -c clean <recipe> + $ bitbake -c clean recipe @@ -338,7 +338,7 @@ If you want to remove the sstate cache files for the recipe, you need to use the do_cleansstate - task instead (i.e. bitbake -c cleansstate <recipe>). + task instead (i.e. bitbake -c cleansstate recipe).
@@ -359,7 +359,7 @@ You can run this task using BitBake as follows: - $ bitbake -c cleanall <recipe> + $ bitbake -c cleanall recipe @@ -389,7 +389,7 @@ You can run this task using BitBake as follows: - $ bitbake -c cleansstate <recipe> + $ bitbake -c cleansstate recipe @@ -404,7 +404,7 @@ If you need to build a target from scratch using remote mirrors, use the "-f" option as follows: - $ bitbake -f -c do_cleansstate <target> + $ bitbake -f -c do_cleansstate target diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml index aadae01ac4..1aabd5c71d 100644 --- a/documentation/ref-manual/ref-variables.xml +++ b/documentation/ref-manual/ref-variables.xml @@ -136,7 +136,7 @@ If ALTERNATIVE_LINK_NAME is not defined, it defaults to - ${bindir}/<name>. + ${bindir}/name. @@ -159,9 +159,9 @@ a default for specific commands tied to particular packages. Here are the available syntax forms: - ALTERNATIVE_PRIORITY = "<priority>" - ALTERNATIVE_PRIORITY[<name>] = "<priority>" - ALTERNATIVE_PRIORITY_<pkg>[<name>] = "<priority>" + ALTERNATIVE_PRIORITY = "priority" + ALTERNATIVE_PRIORITY[name] = "priority" + ALTERNATIVE_PRIORITY_pkg[name] = "priority" @@ -185,9 +185,9 @@ a default for specific commands tied to particular packages. Here are the available syntax forms: - ALTERNATIVE_TARGET = "<target>" - ALTERNATIVE_TARGET[<name>] = "<target>" - ALTERNATIVE_TARGET_<pkg>[<name>] = "<target>" + ALTERNATIVE_TARGET = "target" + ALTERNATIVE_TARGET[name] = "target" + ALTERNATIVE_TARGET_pkg[name] = "target" @@ -338,13 +338,13 @@ being installed by listing them with the BAD_RECOMMENDATIONS variable: - BAD_RECOMMENDATIONS = "<package_name> <package_name> <package_name> ..." + BAD_RECOMMENDATIONS = "package_name package_name package_name ..." You can set this variable globally in your local.conf file or you can attach it to a specific image recipe by using the recipe name override: - BAD_RECOMMENDATIONS_pn-<target_image> = "<package_name>" + BAD_RECOMMENDATIONS_pn-target_image = "package_name" @@ -445,11 +445,11 @@ Build Directory. Use the following form: - BB_DISKMON_DIRS = "<action>,<dir>,<threshold> [...]" + BB_DISKMON_DIRS = "action,dir,threshold [...]" where: - <action> is: + action is: ABORT: Immediately abort the build when a threshold is broken. STOPTASKS: Stop the build after the currently @@ -463,14 +463,14 @@ which must be defined in the conf/local.conf file. - <dir> is: + dir is: Any directory you choose. You can specify one or more directories to monitor by separating the groupings with a space. If two directories are on the same device, only the first directory is monitored. - <threshold> is: + threshold is: Either the minimum available disk space, the minimum number of free inodes, or both. You must specify at least one. To @@ -559,16 +559,16 @@ When specifying the variable in your configuration file, use the following form: - BB_DISKMON_WARNINTERVAL = "<disk_space_interval>,<disk_inode_interval>" + BB_DISKMON_WARNINTERVAL = "disk_space_interval,disk_inode_interval" where: - <disk_space_interval> is: + disk_space_interval is: An interval of memory expressed in either G, M, or K for Gbytes, Mbytes, or Kbytes, respectively. You cannot use GB, MB, or KB. - <disk_inode_interval> is: + disk_inode_interval is: An interval of free inodes expressed in either G, M, or K for Gbytes, Mbytes, or Kbytes, respectively. You cannot use GB, MB, or KB. @@ -643,7 +643,7 @@ which is a compiler built to run on the build machine but produces binaries that run on the target MACHINE; "nativesdk", which targets the SDK machine instead of MACHINE; - and "mulitlibs" in the form "multilib:<multilib_name>". + and "mulitlibs" in the form "multilib:multilib_name". @@ -651,7 +651,7 @@ is as simple as adding the following to your recipe: BBCLASSEXTEND =+ "native nativesdk" - BBCLASSEXTEND =+ "multilib:<multilib_name>" + BBCLASSEXTEND =+ "multilib:multilib_name" @@ -856,9 +856,9 @@ Set the variable as you would any environment variable and then run BitBake: - $ BBPATH = "<build_directory>" + $ BBPATH = "build_directory" $ export BBPATH - $ bitbake <target> + $ bitbake target @@ -2241,7 +2241,7 @@ you want the error reporting tool to store the debug files as follows in your local.conf file: - ERR_REPORT_DIR = "path" + ERR_REPORT_DIR = "path" @@ -2585,11 +2585,11 @@ should have the name of the feature item as an override. Here is an example: - FEATURE_PACKAGES_widget = "package1 package2" + FEATURE_PACKAGES_widget = "package1 package2" In this example, if "widget" were added to - IMAGE_FEATURES, "package1" and - "package2" would be included in the image. + IMAGE_FEATURES, package1 and + package2 would be included in the image. Packages installed by features defined through FEATURE_PACKAGES are often package @@ -3468,7 +3468,7 @@ When you use this variable, it is best to use it as follows: - IMAGE_INSTALL_append = " package-name" + IMAGE_INSTALL_append = " package-name" Be sure to include the space between the quotation character and the start of the package name or names. @@ -3520,7 +3520,7 @@ The file contains package information on a line-per-package basis as follows: - <packagename> <packagearch> <version> + packagename packagearch version @@ -3653,7 +3653,7 @@ OpenEmbedded build system has created the image. You can specify shell commands separated by semicolons: - IMAGE_POSTPROCESS_COMMAND += "<shell_command>; ... " + IMAGE_POSTPROCESS_COMMAND += "shell_command; ... " If you need to pass the path to the root filesystem within the command, you can use @@ -4458,7 +4458,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" Specify it as follows: - KERNEL_MODULE_AUTOLOAD += "modname1 modname2 modname3" + KERNEL_MODULE_AUTOLOAD += "module_name1 module_name2 module_name3" @@ -4470,7 +4470,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" The modules appear one-per-line in the file. Here is an example of the most common use case: - KERNEL_MODULE_AUTOLOAD += "modname" + KERNEL_MODULE_AUTOLOAD += "module_name" @@ -4489,7 +4489,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" Provides a list of modules for which the OpenEmbedded build system expects to find - module_conf_<modname> + module_conf_modname values that specify configuration for each of the modules. For information on how to provide those module configurations, see the @@ -4505,7 +4505,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" The location of the kernel sources. This variable is set to the value of the STAGING_KERNEL_DIR - within the module.bbclass class. + within the + module + class. For information on how this variable is used, see the "Incorporating Out-of-Tree Modules" section. @@ -4530,7 +4532,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" The location of the kernel sources. This variable is set to the value of the STAGING_KERNEL_DIR - within the module.bbclass class. + within the + module + class. For information on how this variable is used, see the "Incorporating Out-of-Tree Modules" section. @@ -4796,10 +4800,10 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" This variable must be defined for all recipes (unless LICENSE - is set to "CLOSED") + is set to "CLOSED"). For more information, see the - - Tracking License Changes section + " + Tracking License Changes" section. @@ -4912,7 +4916,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" The LICENSE_PATH variable allows you to extend that location to other areas that have additional licenses: - LICENSE_PATH += "/path/to/additional/common/licenses" + LICENSE_PATH += "path-to-additional-common-licenses" @@ -5407,7 +5411,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" Here is the general syntax: - module_conf_<modname> = "<modprobe.d syntax>" + module_conf_module_name = "modprobe.d-syntax" You must use the kernel module name override. @@ -5531,7 +5535,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" local.conf file or you can attach it to a specific image recipe by using the recipe name override: - NO_RECOMMENDATIONS_pn-<target_image> = "<package_name>" + NO_RECOMMENDATIONS_pn-target_image = "package_name" @@ -5909,13 +5913,13 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" Lists packages that should not be installed into an image. For example: - PACKAGE_EXCLUDE = "<package_name> <package_name> <package_name> ..." + PACKAGE_EXCLUDE = "package_name package_name package_name ..." You can set this variable globally in your local.conf file or you can attach it to a specific image recipe by using the recipe name override: - PACKAGE_EXCLUDE_pn-<target_image> = "<package_name>" + PACKAGE_EXCLUDE_pn-target_image = "package_name" @@ -6099,8 +6103,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" Append file: Create an append file named - <recipename>.bbappend in your - layer and override the value of + recipename.bbappend + in your layer and override the value of PACKAGECONFIG. You can either completely override the variable: @@ -6114,15 +6118,15 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" This method is identical to changing the block through an append file except you edit your local.conf or - <mydistro>.conf file. + mydistro.conf file. As with append files previously described, you can either completely override the variable: - PACKAGECONFIG_pn-<recipename>="f4 f5" + PACKAGECONFIG_pn-recipename="f4 f5" Or, you can just amend the variable: - PACKAGECONFIG_append_pn-<recipename> = " f4" + PACKAGECONFIG_append_pn-recipename = " f4" @@ -6345,7 +6349,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" For example, when the debian class renames the output package, it does so by setting - PKG_<packagename>. + PKG_packagename. @@ -6868,7 +6872,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" them in conjunction with a package name override. Here is an example: - RCONFLICTS_${PN} = "another-conflicting-package-name" + RCONFLICTS_${PN} = "another-conflicting-package-name" @@ -6880,7 +6884,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" Here is the general syntax to specify versions with the RCONFLICTS variable: - RCONFLICTS_${PN} = "<package> (<operator> <version>)" + RCONFLICTS_${PN} = "package (operator version)" For operator, you can specify the following: @@ -6972,7 +6976,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" as it would in the PACKAGES namespace before any renaming of the output package by classes like - debian.bbclass. + debian. @@ -7006,7 +7010,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" Here is the general syntax to specify versions with the RDEPENDS variable: - RDEPENDS_${PN} = "<package> (<operator> <version>)" + RDEPENDS_${PN} = "package (operator version)" For operator, you can specify the following: @@ -7136,7 +7140,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" OpenEmbedded build system has created the root filesystem. You can specify shell commands separated by semicolons: - ROOTFS_POSTPROCESS_COMMAND += "<shell_command>; ... " + ROOTFS_POSTPROCESS_COMMAND += "shell_command; ... " If you need to pass the path to the root filesystem within the command, you can use @@ -7224,7 +7228,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" that is extended to support wireless functionality. In this case, you would use the following: - RRECOMMENDS_${PN}-dev += "<wireless_package_name>" + RRECOMMENDS_${PN}-dev += "wireless_package_name" In the example, the package name (${PN}-dev) @@ -7242,7 +7246,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" Here is the general syntax to specify versions with the RRECOMMENDS variable: - RRECOMMENDS_${PN} = "<package> (<operator> <version>)" + RRECOMMENDS_${PN} = "package (operator version)" For operator, you can specify the following: @@ -7280,7 +7284,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" override. Here is an example: - RREPLACES_${PN} = "other-package-being-replaced" + RREPLACES_${PN} = "other-package-being-replaced" @@ -7292,7 +7296,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" Here is the general syntax to specify versions with the RREPLACES variable: - RREPLACES_${PN} = "<package> (<operator> <version>)" + RREPLACES_${PN} = "package (operator version)" For operator, you can specify the following: @@ -7327,7 +7331,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" override. Here is an example: - RSUGGESTS_${PN} = "useful-package another-package" + RSUGGESTS_${PN} = "useful-package another-package" @@ -7503,7 +7507,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" However, this variable applies to the SDK generated from an image using the following command: - $ bitbake -c populate_sdk imagename + $ bitbake -c populate_sdk imagename @@ -8083,8 +8087,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" directory structure. SSTATE_MIRRORS ?= "\ - file://.* http://someserver.tld/share/sstate/PATH \n \ - file://.* file:///some/local/dir/sstate/PATH" + file://.* http://someserver.tld/share/sstate/PATH \n \ + file://.* file:///some-local-dir/sstate/PATH" @@ -9090,7 +9094,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" You can add your own tests to the list of tests by appending TEST_SUITES as follows: - TEST_SUITES_append = " mytest" + TEST_SUITES_append = " mytest" Alternatively, you can provide the "auto" option to have all applicable tests run against the image. @@ -9511,11 +9515,11 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" - TUNECONFLICT[<feature>] + TUNECONFLICT[feature] Specifies CPU or Application Binary Interface (ABI) - tuning features that conflict with >feature<. + tuning features that conflict with feature. @@ -9533,7 +9537,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" - TUNEVALID[<feature>] + TUNEVALID[feature] Specifies a valid CPU or Application Binary Interface (ABI) @@ -9644,7 +9648,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" The value indicates the target platform configuration. You typically set this variable from the machine configuration file (i.e. - conf/machine/<machine_name>.conf). + conf/machine/machine_name.conf). diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml index b0588351d5..6bb3381e72 100644 --- a/documentation/ref-manual/technical-details.xml +++ b/documentation/ref-manual/technical-details.xml @@ -85,7 +85,7 @@ - The most common usage for BitBake is bitbake <packagename>, where + The most common usage for BitBake is bitbake packagename, where packagename is the name of the package you want to build (referred to as the "target" in this manual). The target often equates to the first part of a recipe's filename @@ -304,7 +304,8 @@ Here is the bootstrap process for the relocatable toolchain: - gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers -> eglibc-initial -> nativesdk-eglibc -> gcc-crosssdk -> gcc-cross-canadian + gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers -> + eglibc-initial -> nativesdk-eglibc -> gcc-crosssdk -> gcc-cross-canadian gcc: @@ -608,13 +609,13 @@ make some dependency and hash information available to the build. This information includes: - BB_BASEHASH_task-<taskname>: + BB_BASEHASH_task-taskname: The base hashes for each task in the recipe. - BB_BASEHASH_<filename:taskname>: + BB_BASEHASH_filename:taskname: The base hashes for each dependent task. - BBHASHDEPS_<filename:taskname>: + BBHASHDEPS_filename:taskname: The task dependencies for each task. BB_TASKHASH: diff --git a/documentation/ref-manual/usingpoky.xml b/documentation/ref-manual/usingpoky.xml index 283fb725ac..1a211ca78a 100644 --- a/documentation/ref-manual/usingpoky.xml +++ b/documentation/ref-manual/usingpoky.xml @@ -35,12 +35,12 @@ oe-init-build-env-memres). Here is an example: - $ source &OE_INIT_FILE; [<build_dir>] + $ source &OE_INIT_FILE; [build_dir] - The build_dir argument is optional and specifies the directory the + The build_dir argument is optional and specifies the directory the OpenEmbedded build system uses for the build - the Build Directory. If you do not specify a Build Directory, it defaults to a directory @@ -53,12 +53,12 @@ Once the build environment is set up, you can build a target using: - $ bitbake <target> + $ bitbake target - The target is the name of the recipe you want to build. + The target is the name of the recipe you want to build. Common targets are the images in meta/recipes-core/images, meta/recipes-sato/images, etc. all found in the Source Directory. @@ -154,14 +154,14 @@ Task Failures The log file for shell tasks is available in - ${WORKDIR}/temp/log.do_taskname.pid. - For example, the compile task for the QEMU minimal image for the x86 + ${WORKDIR}/temp/log.do_taskname.pid. + For example, the do_compile task for the QEMU minimal image for the x86 machine (qemux86) might be tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile.20830. To see what BitBake runs to generate that log, look at the corresponding - run.do_taskname.pid file located in the same directory. + run.do_taskname.pid file located in the same directory. @@ -203,7 +203,7 @@ $ bitbake matchbox-desktop . . - [make some changes to the source code in the work directory] + make some changes to the source code in the work directory . . $ bitbake matchbox-desktop -c compile -f @@ -238,7 +238,7 @@ Sometimes it can be hard to see why BitBake wants to build other packages before building a given package you have specified. - The bitbake -g <targetname> command + The bitbake -g targetname command creates the pn-buildlist, pn-depends.dot, package-depends.dot, and @@ -247,7 +247,7 @@ These files show what will be built and the package and task dependencies, which are useful for debugging problems. You can use the - bitbake -g -u depexp <targetname> + bitbake -g -u depexp targetname command to display the results in a more human-readable form. @@ -264,7 +264,7 @@ - The output from bitbake -DDD -v targetname can reveal why + The output from bitbake -DDD -v targetname can reveal why BitBake chose a certain version of a package or why BitBake picked a certain provider. This command could also help you in a situation where you think BitBake did something @@ -310,7 +310,7 @@ To build a specific recipe (.bb file), you can use the following command form: - $ bitbake -b <somepath/somerecipe.bb> + $ bitbake -b somepath/somerecipe.bb This command form does not check for dependencies. Consequently, you should use it @@ -334,7 +334,7 @@ This next example shows the parsing environment for a specific recipe: - $ bitbake -e <recipename> + $ bitbake -e recipename -- cgit v1.2.3-54-g00ecf