summaryrefslogtreecommitdiffstats
path: root/documentation
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2011-04-04 18:17:46 -0500
committerRichard Purdie <richard.purdie@linuxfoundation.org>2011-04-06 08:01:23 -0700
commit6a0d070addd87ac52b4f82d823d683fa252cee97 (patch)
treea75cb2482af9e1226341234b5274f80717dc6b24 /documentation
parent1cd9b0cb5bd25730baba368d562f21985e5b622f (diff)
downloadast2050-yocto-poky-6a0d070addd87ac52b4f82d823d683fa252cee97.zip
ast2050-yocto-poky-6a0d070addd87ac52b4f82d823d683fa252cee97.tar.gz
documentation/poky-ref-manual/ref-bitbake.xml: style tags updated
I got rid of the <filename class='directory'...> and <filename class='extension'...> and replaced with simple <filename>/</filename> pairs. (From OE-Core rev: 1bcdaf8d3d39680c154144227ee2caca9a7bb3e5) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation')
-rw-r--r--documentation/poky-ref-manual/ref-bitbake.xml36
1 files changed, 18 insertions, 18 deletions
diff --git a/documentation/poky-ref-manual/ref-bitbake.xml b/documentation/poky-ref-manual/ref-bitbake.xml
index d870387..75b3bf5 100644
--- a/documentation/poky-ref-manual/ref-bitbake.xml
+++ b/documentation/poky-ref-manual/ref-bitbake.xml
@@ -33,15 +33,15 @@
<para>
The first thing BitBake does is look for the <filename>bitbake.conf</filename> file.
- Poky keeps this file in <filename class="directory">meta/conf/</filename>.
+ Poky keeps this file in <filename>meta/conf/</filename>.
BitBake finds it by examining the <filename>BBPATH</filename> environment
- variable and looking for the <filename class="directory">meta/conf/</filename>
+ variable and looking for the <filename>meta/conf/</filename>
directory.
</para>
<para>
In Poky, <filename>bitbake.conf</filename> lists other configuration
- files to include from a <filename class="directory">conf/</filename>
+ files to include from a <filename>conf/</filename>
directory below the directories listed in <filename>BBPATH</filename>.
In general the most important configuration file from a user's perspective
is <filename>local.conf</filename>, which contains a user's customized
@@ -54,11 +54,11 @@
The DISTRO and MACHINE environment variables are both usually set in
the <filename>local.conf</filename> file.
Valid distribution
- configuration files are available in the <filename class="directory">
+ configuration files are available in the <filename>
meta/conf/distro/</filename> directory and valid machine configuration
- files in the <filename class="directory">meta/conf/machine/</filename>
+ files in the <filename>meta/conf/machine/</filename>
directory.
- Within the <filename class="directory">meta/conf/machine/include/</filename>
+ Within the <filename>meta/conf/machine/include/</filename>
directory are various <filename>tune-*.inc</filename> configuration files that provide common
"tuning" settings specific to and shared between particular architectures and machines.
</para>
@@ -79,29 +79,29 @@
variable <glossterm><link linkend='var-BBFILES'>BBFILES</link></glossterm>
is set, usually in
<filename>local.conf</filename>, and defines the list of places to search for
- <filename class="extension">.bb</filename> files.
- By default, the BBFILES variable specifies the <filename class="directory">meta/recipes-*/
+ <filename>.bb</filename> files.
+ By default, the BBFILES variable specifies the <filename>meta/recipes-*/
</filename> directory within Poky.
Adding extra content to BBFILES is best achieved through the use of BitBake
<link linkend='usingpoky-changes-layers'>"layers"</link>.
</para>
<para>
- BitBake parses each <filename class="extension">.bb</filename> file in BBFILES and
+ BitBake parses each <filename>.bb</filename> file in BBFILES and
stores the values of various variables.
- In summary, for each <filename class="extension">.bb</filename>
+ In summary, for each <filename>.bb</filename>
file the configuration plus the base class of variables are set, followed
- by the data in the <filename class="extension">.bb</filename> file
+ by the data in the <filename>.bb</filename> file
itself, followed by any inherit commands that
- <filename class="extension">.bb</filename> file might contain.
+ <filename>.bb</filename> file might contain.
</para>
<para>
- Because parsing <filename class="extension">.bb</filename> files is a time
+ Because parsing <filename>.bb</filename> files is a time
consuming process, a cache is kept to speed up subsequent parsing.
- This cache is invalid if the timestamp of the <filename class="extension">.bb</filename>
+ This cache is invalid if the timestamp of the <filename>.bb</filename>
file itself changes, or if the timestamps of any of the include,
- configuration or class files the <filename class="extension">.bb</filename>
+ configuration or class files the <filename>.bb</filename>
file depends on changes.
</para>
</section>
@@ -110,7 +110,7 @@
<title>Preferences and Providers</title>
<para>
- Once all the <filename class="extension">.bb</filename> files have been
+ Once all the <filename>.bb</filename> files have been
parsed, BitBake starts to build the target (poky-image-sato in the previous section's
example) and looks for providers of that target.
Once a provider is selected, BitBake resolves all the dependencies for
@@ -200,11 +200,11 @@ PREFERRED_PROVIDER_virtual/kernel = "linux-rp"
<para>
As each task completes, a timestamp is written to the directory specified by the
<glossterm><link linkend='var-STAMPS'>STAMPS</link></glossterm> variable (usually
- <filename class="directory">build/tmp/stamps/*/</filename>).
+ <filename>build/tmp/stamps/*/</filename>).
On subsequent runs, BitBake looks at the STAMPS 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
- <filename class="extension">.bb</filename> file basis.
+ <filename>.bb</filename> file basis.
So, for example, if the configure stamp has a timestamp greater than the
compile timestamp for a given target then the compile task would rerun.
Running the compile task again, however, has no effect on other providers
OpenPOWER on IntegriCloud