From 6a0d070addd87ac52b4f82d823d683fa252cee97 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 4 Apr 2011 18:17:46 -0500 Subject: documentation/poky-ref-manual/ref-bitbake.xml: style tags updated I got rid of the and and replaced with simple / pairs. (From OE-Core rev: 1bcdaf8d3d39680c154144227ee2caca9a7bb3e5) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/poky-ref-manual/ref-bitbake.xml | 36 +++++++++++++-------------- 1 file changed, 18 insertions(+), 18 deletions(-) (limited to 'documentation') 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 @@ The first thing BitBake does is look for the bitbake.conf file. - Poky keeps this file in meta/conf/. + Poky keeps this file in meta/conf/. BitBake finds it by examining the BBPATH environment - variable and looking for the meta/conf/ + variable and looking for the meta/conf/ directory. In Poky, bitbake.conf lists other configuration - files to include from a conf/ + files to include from a conf/ directory below the directories listed in BBPATH. In general the most important configuration file from a user's perspective is local.conf, which contains a user's customized @@ -54,11 +54,11 @@ The DISTRO and MACHINE environment variables are both usually set in the local.conf file. Valid distribution - configuration files are available in the + configuration files are available in the meta/conf/distro/ directory and valid machine configuration - files in the meta/conf/machine/ + files in the meta/conf/machine/ directory. - Within the meta/conf/machine/include/ + Within the meta/conf/machine/include/ directory are various tune-*.inc configuration files that provide common "tuning" settings specific to and shared between particular architectures and machines. @@ -79,29 +79,29 @@ variable BBFILES is set, usually in local.conf, and defines the list of places to search for - .bb files. - By default, the BBFILES variable specifies the meta/recipes-*/ + .bb files. + By default, the BBFILES variable specifies the meta/recipes-*/ directory within Poky. Adding extra content to BBFILES is best achieved through the use of BitBake "layers". - BitBake parses each .bb file in BBFILES and + BitBake parses each .bb file in BBFILES and stores the values of various variables. - In summary, for each .bb + In summary, for each .bb file the configuration plus the base class of variables are set, followed - by the data in the .bb file + by the data in the .bb file itself, followed by any inherit commands that - .bb file might contain. + .bb file might contain. - Because parsing .bb files is a time + Because parsing .bb files is a time consuming process, a cache is kept to speed up subsequent parsing. - This cache is invalid if the timestamp of the .bb + This cache is invalid if the timestamp of the .bb file itself changes, or if the timestamps of any of the include, - configuration or class files the .bb + configuration or class files the .bb file depends on changes. @@ -110,7 +110,7 @@ Preferences and Providers - Once all the .bb files have been + Once all the .bb 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" As each task completes, a timestamp is written to the directory specified by the STAMPS variable (usually - build/tmp/stamps/*/). + build/tmp/stamps/*/). 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 - .bb file basis. + .bb 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 -- cgit v1.1