documentation: Scrubbed use of directory names
There was inconsistent use of the way directory names were handled throughout the YP documentation. I have scrubbed the set and replaced many instances such as the following: meta/<something> replaces /meta/<something> poky replaces ~/poky (except in some very specific examples) I basically got rid of leading slash characters. Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> (From yocto-docs rev: 12a96db6dffe09fca7ce848e006c591a637be5a4) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
parent
a665b9b68e
commit
9addcf5ccb
|
@ -106,7 +106,7 @@
|
|||
build environment while also creating the default
|
||||
Build Directory, and run the BitBake command that
|
||||
results in the tarball
|
||||
<filename>~/yocto-project/build/tmp/deploy/sdk/adt_installer.tar.bz2</filename>:
|
||||
<filename>poky/build/tmp/deploy/sdk/adt_installer.tar.bz2</filename>:
|
||||
<note>
|
||||
Before using BitBake to build the ADT tarball, be
|
||||
sure to make sure your
|
||||
|
@ -136,7 +136,7 @@
|
|||
a top-level directory named <filename>adt-installer</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~
|
||||
$ cp ~/poky/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME
|
||||
$ cp poky/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME
|
||||
$ tar -xjf adt_installer.tar.bz2
|
||||
</literallayout>
|
||||
Unpacking it creates the directory <filename>adt-installer</filename>,
|
||||
|
@ -206,7 +206,7 @@
|
|||
When you run the installer, the environment must use a
|
||||
host <filename>gcc</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~/adt-installer
|
||||
$ cd adt-installer
|
||||
$ ./adt_installer
|
||||
</literallayout>
|
||||
Once the installer begins to run, you are asked to enter the
|
||||
|
@ -303,7 +303,7 @@
|
|||
The first thing the installer prompts you for is the
|
||||
directory into which you want to install the toolchain.
|
||||
The default directory used is
|
||||
<filename>opt/poky/&DISTRO;</filename>.
|
||||
<filename>/opt/poky/&DISTRO;</filename>.
|
||||
If you do not have write permissions for the directory
|
||||
into which you are installing the toolchain, the
|
||||
toolchain installer notifies you and exits.
|
||||
|
@ -545,7 +545,7 @@
|
|||
the toolchain environment script in the
|
||||
<filename>tmp</filename> directory.
|
||||
If you installed the toolchain by hand, the environment setup
|
||||
script is located in <filename>opt/poky/&DISTRO;</filename>.
|
||||
script is located in <filename>/opt/poky/&DISTRO;</filename>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -563,16 +563,16 @@
|
|||
built filesystem that is located in the
|
||||
<filename>~/Downloads</filename> directory.
|
||||
Furthermore, this command extracts the root filesystem into the
|
||||
<filename>$HOME/qemux86-sato</filename> directory:
|
||||
<filename>qemux86-sato</filename> directory:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~
|
||||
$ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
|
||||
$ runqemu-extract-sdk \
|
||||
~Downloads/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2 \
|
||||
~/Downloads/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2 \
|
||||
$HOME/qemux86-sato
|
||||
</literallayout>
|
||||
You could now point to the target sysroot at
|
||||
<filename>$HOME/qemux86-sato</filename>.
|
||||
<filename>qemux86-sato</filename>.
|
||||
</para>
|
||||
</section>
|
||||
</section>
|
||||
|
@ -625,13 +625,13 @@
|
|||
<note>
|
||||
By default, this toolchain does not build static binaries.
|
||||
If you want to use the toolchain to build these types of libraries,
|
||||
you need to be sure your image has the appropriate static
|
||||
you need to be sure your image has the appropriate static
|
||||
development libraries.
|
||||
Use the
|
||||
Use the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></ulink>
|
||||
variable inside your <filename>local.conf</filename> file to
|
||||
install the appropriate library packages.
|
||||
Following is an example using <filename>eglibc</filename> static
|
||||
Following is an example using <filename>eglibc</filename> static
|
||||
development libraries:
|
||||
<literallayout class='monospaced'>
|
||||
IMAGE_INSTALL_append = " eglibc-staticdev"
|
||||
|
|
|
@ -562,7 +562,7 @@
|
|||
<para>
|
||||
For example, suppose you had some configuration options in a file called
|
||||
<filename>network_configs.cfg</filename>.
|
||||
You can place that file inside a directory named <filename>/linux-yocto</filename> and then add
|
||||
You can place that file inside a directory named <filename>linux-yocto</filename> and then add
|
||||
a <filename>SRC_URI</filename> statement such as the following to the append file.
|
||||
When the OpenEmbedded build system builds the kernel, the configuration options are
|
||||
picked up and applied.
|
||||
|
@ -748,7 +748,7 @@
|
|||
<listitem><para>Instructions on how to boot the BSP build from
|
||||
the BSP layer.</para></listitem>
|
||||
<listitem><para>Instructions on how to boot the binary images
|
||||
contained in the <filename>/binary</filename> directory,
|
||||
contained in the <filename>binary</filename> directory,
|
||||
if present.</para></listitem>
|
||||
<listitem><para>Information on any known bugs or issues that users
|
||||
should know about when either building or booting the BSP
|
||||
|
@ -759,7 +759,7 @@
|
|||
<filename>meta-<bsp_name></filename> directory.
|
||||
This file specifies exactly where you can find the sources used to
|
||||
generate the binary images contained in the
|
||||
<filename>/binary</filename> directory, if present.
|
||||
<filename>binary</filename> directory, if present.
|
||||
See the
|
||||
<ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/README.sources'><filename>README.sources</filename></ulink>
|
||||
file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer
|
||||
|
|
|
@ -357,7 +357,7 @@
|
|||
to cause the build to use your own version of
|
||||
the file.
|
||||
For example, an append file in your layer at
|
||||
<filename>/meta-one/recipes-core/base-files/base-files.bbappend</filename>
|
||||
<filename>meta-one/recipes-core/base-files/base-files.bbappend</filename>
|
||||
could extend
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
|
||||
using
|
||||
|
@ -369,7 +369,7 @@
|
|||
The build for machine "one" will pick up your
|
||||
machine-specific file as long as you have the
|
||||
file in
|
||||
<filename>/meta-one/recipes-core/base-files/base-files/</filename>.
|
||||
<filename>meta-one/recipes-core/base-files/base-files/</filename>.
|
||||
However, if you are building for a different
|
||||
machine and the
|
||||
<filename>bblayers.conf</filename> file includes
|
||||
|
@ -384,9 +384,9 @@
|
|||
the file in a subdirectory specific to the
|
||||
machine.
|
||||
For example, rather than placing the file in
|
||||
<filename>/meta-one/recipes-core/base-files/base-files/</filename>
|
||||
<filename>meta-one/recipes-core/base-files/base-files/</filename>
|
||||
as shown above, put it in
|
||||
<filename>/meta-one/recipes-core/base-files/base-files/one/</filename>.
|
||||
<filename>meta-one/recipes-core/base-files/base-files/one/</filename>.
|
||||
Not only does this make sure the file is used
|
||||
only when building for machine "one" but the
|
||||
build process locates the file more quickly.</para>
|
||||
|
@ -1957,7 +1957,7 @@
|
|||
<link linkend='source-directory'>Source Directory</link>
|
||||
top-level folder is <filename>~/poky</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~/poky
|
||||
$ cd poky
|
||||
$ source oe-init-build-env
|
||||
$ bitbake linux-yocto -c menuconfig
|
||||
</literallayout>
|
||||
|
@ -2006,7 +2006,7 @@
|
|||
<filename>x86</filename> architecture, the
|
||||
<filename>.config</filename> file would be located here:
|
||||
<literallayout class='monospaced'>
|
||||
~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.4.11+git1+84f...
|
||||
poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.4.11+git1+84f...
|
||||
...656ed30-r1/linux-qemux86-standard-build
|
||||
</literallayout>
|
||||
<note>
|
||||
|
@ -2079,7 +2079,7 @@
|
|||
kernel's configuration.
|
||||
For example, suppose you had a set of configuration options in a file called
|
||||
<filename>myconfig.cfg</filename>.
|
||||
If you put that file inside a directory named <filename>/linux-yocto</filename>
|
||||
If you put that file inside a directory named <filename>linux-yocto</filename>
|
||||
that resides in the same directory as the kernel's append file and then add
|
||||
a <filename>SRC_URI</filename> statement such as the following to the kernel's append file,
|
||||
those configuration options will be picked up and applied when the kernel is built.
|
||||
|
@ -5271,7 +5271,7 @@
|
|||
<listitem><para>You have checked out the
|
||||
<filename>dora-toaster</filename> branch:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~/poky
|
||||
$ cd poky
|
||||
$ git checkout -b dora-toaster origin/dora-toaster
|
||||
</literallayout></para></listitem>
|
||||
<listitem><para>Be sure your build machine has
|
||||
|
@ -5595,7 +5595,7 @@
|
|||
<para>
|
||||
Downloaded archives reside in the
|
||||
<link linkend='build-directory'>Build Directory</link> in
|
||||
<filename>/tmp</filename> and are cleared up when they are no longer in use.
|
||||
<filename>tmp</filename> and are cleared up when they are no longer in use.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
|
@ -1674,7 +1674,7 @@
|
|||
the following is the work directory for the <filename>acl</filename> recipe that
|
||||
creates the <filename>acl</filename> package:
|
||||
<literallayout class='monospaced'>
|
||||
~/poky/build/tmp/work/i586-poky-linux/acl/2.2.51-r3/
|
||||
poky/build/tmp/work/i586-poky-linux/acl/2.2.51-r3/
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
@ -1690,8 +1690,8 @@
|
|||
for the <filename>acl</filename> package that is being
|
||||
built for a MIPS-based device:
|
||||
<literallayout class='monospaced'>
|
||||
~/poky/build/tmp/work/mips-poky-linux/acl/2.2.51-r2
|
||||
~/poky/build/tmp/work/mips-poky-linux/acl/2.2.51-r2/acl-2.2.51
|
||||
poky/build/tmp/work/mips-poky-linux/acl/2.2.51-r2
|
||||
poky/build/tmp/work/mips-poky-linux/acl/2.2.51-r2/acl-2.2.51
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
|
|
@ -1459,8 +1459,8 @@
|
|||
<para>For help on using these scripts, simply provide the
|
||||
<filename>-h</filename> argument as follows:
|
||||
<literallayout class='monospaced'>
|
||||
$ ~/poky/scripts/create-pull-request -h
|
||||
$ ~/poky/scripts/send-pull-request -h
|
||||
$ poky/scripts/create-pull-request -h
|
||||
$ poky/scripts/send-pull-request -h
|
||||
</literallayout></para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
|
|
@ -45,7 +45,7 @@
|
|||
Here is an example that assumes the local Git repository for the kernel is in
|
||||
a top-level directory named <filename>linux-yocto-3.4</filename>:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd ~/linux-yocto-3.4
|
||||
$ cd linux-yocto-3.4
|
||||
$ git checkout -b meta origin/meta
|
||||
</literallayout>
|
||||
Once you have checked out and switched to the <filename>meta</filename> branch,
|
||||
|
@ -208,7 +208,7 @@
|
|||
the build tree directory.
|
||||
The files include the final <filename>.config</filename> file, all the <filename>.o</filename>
|
||||
files, the <filename>.a</filename> files, and so forth.
|
||||
Since each machine or BSP has its own separate
|
||||
Since each machine or BSP has its own separate
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
|
||||
in its own separate branch
|
||||
of the Git repository, you can easily switch between different builds.
|
||||
|
|
|
@ -829,10 +829,10 @@
|
|||
</section>
|
||||
|
||||
<section id='migration-1.5-run'>
|
||||
<title><filename>/run</filename></title>
|
||||
<title><filename>run</filename></title>
|
||||
|
||||
<para>
|
||||
The <filename>/run</filename> directory from the Filesystem
|
||||
The <filename>run</filename> directory from the Filesystem
|
||||
Hierarchy Standard 3.0 has been introduced.
|
||||
You can find some of the implications for this change
|
||||
<ulink url='http://cgit.openembedded.org/openembedded-core/commit/?id=0e326280a15b0f2c4ef2ef4ec441f63f55b75873'>here</ulink>.
|
||||
|
@ -1033,7 +1033,7 @@
|
|||
</para></listitem>
|
||||
<listitem><para>
|
||||
<filename>base-files</filename>: Remove the unnecessary
|
||||
<filename>/media/xxx</filename> directories.
|
||||
<filename>media/xxx</filename> directories.
|
||||
</para></listitem>
|
||||
<listitem><para>
|
||||
<filename>alsa-state</filename>: Provide an empty
|
||||
|
|
|
@ -222,7 +222,7 @@
|
|||
<para>
|
||||
As each task completes, a timestamp is written to the directory specified by the
|
||||
<filename><link linkend='var-STAMP'>STAMP</link></filename> variable.
|
||||
On subsequent runs, BitBake looks within the <filename>/build/tmp/stamps</filename>
|
||||
On subsequent runs, BitBake looks within the <filename>build/tmp/stamps</filename>
|
||||
directory and does not rerun
|
||||
tasks that are already completed unless a timestamp is found to be invalid.
|
||||
Currently, invalid timestamps are only considered on a per
|
||||
|
|
|
@ -38,7 +38,7 @@
|
|||
Here is an example that discovers the recipes whose build is potentially
|
||||
changed based on a given feature:
|
||||
<literallayout class='monospaced'>
|
||||
$ cd $HOME/poky
|
||||
$ cd poky
|
||||
$ git grep 'contains.*MACHINE_FEATURES.*<feature>'
|
||||
</literallayout>
|
||||
</para>
|
||||
|
|
|
@ -701,10 +701,10 @@
|
|||
<para>
|
||||
The following example uses a complete regular expression
|
||||
to tell BitBake to ignore all recipe and recipe append
|
||||
files in the <filename>/meta-ti/recipes-misc/</filename>
|
||||
files in the <filename>meta-ti/recipes-misc/</filename>
|
||||
directory:
|
||||
<literallayout class='monospaced'>
|
||||
BBMASK = "/meta-ti/recipes-misc/"
|
||||
BBMASK = "meta-ti/recipes-misc/"
|
||||
</literallayout>
|
||||
If you want to mask out multiple directories or recipes,
|
||||
use the vertical bar to separate the regular expression
|
||||
|
@ -999,7 +999,7 @@
|
|||
<filename>/etc</filename> or <filename>${bindir}</filename> rather
|
||||
than <filename>/usr/bin</filename>.
|
||||
You can find a list of these variables at the top of the
|
||||
<filename>/meta/conf/bitbake.conf</filename> file in the
|
||||
<filename>meta/conf/bitbake.conf</filename> file in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
</note>
|
||||
</glossdef>
|
||||
|
@ -1036,7 +1036,7 @@
|
|||
<glossdef>
|
||||
<para>
|
||||
Specifies the parent directory of the OpenEmbedded
|
||||
Core Metadata layer (i.e. <filename>/meta</filename>).
|
||||
Core Metadata layer (i.e. <filename>meta</filename>).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -1362,7 +1362,7 @@
|
|||
<para>
|
||||
You can set this directory by defining the
|
||||
<filename>DL_DIR</filename> variable in the
|
||||
<filename>/conf/local.conf</filename> file.
|
||||
<filename>conf/local.conf</filename> file.
|
||||
This directory is self-maintaining and you should not have
|
||||
to touch it.
|
||||
By default, the directory is <filename>downloads</filename>
|
||||
|
@ -1712,7 +1712,7 @@
|
|||
<filename>/etc</filename>, or <filename>${bindir}</filename> rather
|
||||
than <filename>/usr/bin</filename>.
|
||||
You can find a list of these variables at the top of the
|
||||
<filename>/meta/conf/bitbake.conf</filename> file in the
|
||||
<filename>meta/conf/bitbake.conf</filename> file in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
</note>
|
||||
|
||||
|
@ -2068,7 +2068,7 @@
|
|||
to a default value using the <filename>?=</filename> operator, using a
|
||||
<filename>+=</filename> operation against <filename>IMAGE_INSTALL</filename>
|
||||
will result in unexpected behavior when used in
|
||||
<filename>/conf/local.conf</filename>.
|
||||
<filename>conf/local.conf</filename>.
|
||||
Furthermore, the same operation from within an image recipe may or may not
|
||||
succeed depending on the specific situation.
|
||||
In both these cases, the behavior is contrary to how most users expect
|
||||
|
@ -4770,7 +4770,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
|
|||
to keep the unpacked recipe for <filename>db</filename>
|
||||
is the following:
|
||||
<literallayout class='monospaced'>
|
||||
~/poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19
|
||||
poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19
|
||||
</literallayout>
|
||||
</para>
|
||||
</glossdef>
|
||||
|
@ -5888,7 +5888,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
|
|||
In this case, the working directory the build system uses to build
|
||||
the <filename>v86d</filename> package is the following:
|
||||
<literallayout class='monospaced'>
|
||||
~/poky/build/tmp/work/qemux86-poky-linux/v86d/01.9-r0
|
||||
poky/build/tmp/work/qemux86-poky-linux/v86d/01.9-r0
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
@ -5905,7 +5905,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
|
|||
the <filename>acl</filename> recipe, which is being built for a
|
||||
MIPS-based device, is the following:
|
||||
<literallayout class='monospaced'>
|
||||
~/poky/build/tmp/work/mips-poky-linux/acl/2.2.51-r2
|
||||
poky/build/tmp/work/mips-poky-linux/acl/2.2.51-r2
|
||||
</literallayout>
|
||||
</para>
|
||||
</glossdef>
|
||||
|
|
|
@ -1149,7 +1149,7 @@
|
|||
recipe-by-recipe basis through the <filename>LICENSE_FLAGS</filename> variable
|
||||
definition in the affected recipe.
|
||||
For instance, the
|
||||
<filename>$HOME/poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
|
||||
<filename>poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
|
||||
recipe contains the following statement:
|
||||
<literallayout class='monospaced'>
|
||||
LICENSE_FLAGS = "commercial"
|
||||
|
@ -1165,7 +1165,7 @@
|
|||
<filename>LICENSE_FLAGS_WHITELIST</filename> variable, which is a variable
|
||||
typically defined in your <filename>local.conf</filename> file.
|
||||
For example, to enable
|
||||
the <filename>$HOME/poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
|
||||
the <filename>poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
|
||||
package, you could add either the string
|
||||
"commercial_gst-plugins-ugly" or the more general string
|
||||
"commercial" to <filename>LICENSE_FLAGS_WHITELIST</filename>.
|
||||
|
@ -1312,7 +1312,7 @@
|
|||
<para>
|
||||
Other helpful variables related to commercial
|
||||
license handling exist and are defined in the
|
||||
<filename>$HOME/poky/meta/conf/distro/include/default-distrovars.inc</filename> file:
|
||||
<filename>poky/meta/conf/distro/include/default-distrovars.inc</filename> file:
|
||||
<literallayout class='monospaced'>
|
||||
COMMERCIAL_AUDIO_PLUGINS ?= ""
|
||||
COMMERCIAL_VIDEO_PLUGINS ?= ""
|
||||
|
|
|
@ -62,7 +62,7 @@
|
|||
<para>
|
||||
The <filename>target</filename> is the name of the recipe you want to build.
|
||||
Common targets are the images in <filename>meta/recipes-core/images</filename>,
|
||||
<filename>/meta/recipes-sato/images</filename>, etc. all found in the
|
||||
<filename>meta/recipes-sato/images</filename>, etc. all found in the
|
||||
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
|
||||
Or, the target can be the name of a recipe for a specific piece of software such as
|
||||
BusyBox.
|
||||
|
|
Loading…
Reference in New Issue