From 8615d47a3a39e78fb7cf29ee92203d18a2439a3b Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Wed, 26 Dec 2018 16:22:32 -0800 Subject: bitbake: bitbake-user-manual: Created unique tags for glossary variables. Fixes [YOCTO #12399] The bug was to get the BitBake User Manual into the YP Mega-manual. All the changes here create unique tags used with variables in the BitBake Manual. Prior to the fix, tags were identical between like variables in the YP reference manual and the BitBake User Manual. The reason for this is because when I created the BitBake manual's glossary, it was a cut-and-paste operation to get the bulk of the work started. At the time, the BitBake User Manual was not a part of the Mega-manual. Once we decided to include the BitBake User Manual as part of the Mega-Manual, building the mega-manual produced warnings for all these duplicate links. To fix, I have updated the variable tags in the BitBake User Manual to use the following form: 'var-bb-' The tags used in the YP ref-manual follow this form (original): 'var-' (Bitbake rev: fb6de2057aae3fbdf37f007d2e47794b332020e1) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- .../bitbake-user-manual-execution.xml | 78 +++++++++++----------- 1 file changed, 39 insertions(+), 39 deletions(-) (limited to 'bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml') diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml index f1caaecd2d..46dafeee30 100644 --- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml +++ b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml @@ -31,7 +31,7 @@ Prior to executing BitBake, you should take advantage of available parallel thread execution on your build host by setting the - BB_NUMBER_THREADS + BB_NUMBER_THREADS variable in your project's local.conf configuration file. @@ -87,9 +87,9 @@ The layer.conf files are used to construct key variables such as - BBPATH + BBPATH and - BBFILES. + BBFILES. BBPATH is used to search for configuration and class files under the conf and classes @@ -117,19 +117,19 @@ at certain variables, including: - BB_ENV_WHITELIST + BB_ENV_WHITELIST - BB_ENV_EXTRAWHITE + BB_ENV_EXTRAWHITE - BB_PRESERVE_ENV + BB_PRESERVE_ENV - BB_ORIGENV + BB_ORIGENV - BITBAKE_UI + BITBAKE_UI The first four variables in this list relate to how BitBake treats shell @@ -156,7 +156,7 @@ BitBake first searches the current working directory for an optional conf/bblayers.conf configuration file. This file is expected to contain a - BBLAYERS + BBLAYERS variable that is a space-delimited list of 'layer' directories. Recall that if BitBake cannot find a bblayers.conf file, then it is assumed the user has set the BBPATH @@ -166,10 +166,10 @@ For each directory (layer) in this list, a conf/layer.conf file is located and parsed with the - LAYERDIR + LAYERDIR variable being set to the directory where the layer was found. The idea is these files automatically set up - BBPATH + BBPATH and other variables correctly for a given build directory. @@ -189,7 +189,7 @@ depending on the environment variables previously mentioned or set in the configuration files. The - "Variables Glossary" + "Variables Glossary" chapter presents a full list of variables. @@ -204,7 +204,7 @@ The base.bbclass file is always included. Other classes that are specified in the configuration using the - INHERIT + INHERIT variable are also included. BitBake searches for class files in a classes subdirectory under @@ -270,7 +270,7 @@ During the configuration phase, BitBake will have set - BBFILES. + BBFILES. BitBake now uses it to construct a list of recipes to parse, along with any append files (.bbappend) to apply. @@ -292,7 +292,7 @@ Any inherit statements cause BitBake to find and then parse class files (.bbclass) using - BBPATH + BBPATH as the search path. Finally, BitBake parses in order any append files found in BBFILES. @@ -303,8 +303,8 @@ pieces of metadata. For example, in bitbake.conf the recipe name and version are used to set the variables - PN and - PV: + PN and + PV: PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" PV = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}" @@ -336,7 +336,7 @@ recipe information. The validity of this cache is determined by first computing a checksum of the base configuration data (see - BB_HASHCONFIG_WHITELIST) + BB_HASHCONFIG_WHITELIST) and then checking if the checksum matches. If that checksum matches what is in the cache and the recipe and class files have not changed, Bitbake is able to use @@ -384,9 +384,9 @@ the recipe can be known. Each recipe's PROVIDES list is created implicitly through the recipe's - PN variable + PN variable and explicitly through the recipe's - PROVIDES + PROVIDES variable, which is optional. @@ -427,7 +427,7 @@ PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" The default - PREFERRED_PROVIDER + PREFERRED_PROVIDER is the provider with the same name as the target. Bitbake iterates through each target it needs to build and resolves them and their dependencies using this process. @@ -439,10 +439,10 @@ BitBake defaults to the highest version of a provider. Version comparisons are made using the same method as Debian. You can use the - PREFERRED_VERSION + PREFERRED_VERSION variable to specify a particular version. You can influence the order by using the - DEFAULT_PREFERENCE + DEFAULT_PREFERENCE variable. @@ -464,7 +464,7 @@ BitBake defaults to selecting the most recent version, unless otherwise specified. If the recipe in question has a - DEFAULT_PREFERENCE + DEFAULT_PREFERENCE set lower than the other recipes (default is 0), then it will not be selected. This allows the person or persons maintaining @@ -475,9 +475,9 @@ If the first recipe is named a_1.1.bb, then the - PN variable + PN variable will be set to “a”, and the - PV + PV variable will be set to 1.1. @@ -532,11 +532,11 @@ Dependencies are defined through several variables. You can find information about variables BitBake uses in - the Variables Glossary + the Variables Glossary near the end of this manual. At a basic level, it is sufficient to know that BitBake uses the - DEPENDS and - RDEPENDS variables when + DEPENDS and + RDEPENDS variables when calculating dependencies. @@ -560,7 +560,7 @@ The build now starts with BitBake forking off threads up to the limit set in the - BB_NUMBER_THREADS + BB_NUMBER_THREADS variable. BitBake continues to fork threads as long as there are tasks ready to run, those tasks have all their dependencies met, and the thread threshold has not been @@ -574,7 +574,7 @@ As each task completes, a timestamp is written to the directory specified by the - STAMP variable. + STAMP variable. On subsequent runs, BitBake looks in the build directory within tmp/stamps and does not rerun tasks that are already completed unless a timestamp is found to be invalid. @@ -618,7 +618,7 @@ Tasks can be either a shell task or a Python task. For shell tasks, BitBake writes a shell script to - ${T}/run.do_taskname.pid + ${T}/run.do_taskname.pid and then executes the script. The generated shell script contains all the exported variables, and the shell functions with all variables expanded. @@ -645,10 +645,10 @@ behavior: - BB_SCHEDULER + BB_SCHEDULER - BB_SCHEDULERS + BB_SCHEDULERS It is possible to have functions run before and after a task's main @@ -684,7 +684,7 @@ The simplistic approach for excluding the working directory is to set it to some fixed value and create the checksum for the "run" script. BitBake goes one step better and uses the - BB_HASHBASE_WHITELIST + BB_HASHBASE_WHITELIST variable to define a list of variables that should never be included when generating the signatures. @@ -795,7 +795,7 @@ This results in any metadata change that changes the task hash, automatically causing the task to be run again. This removes the need to bump - PR + PR values, and changes to metadata automatically ripple across the build. @@ -884,7 +884,7 @@ BitBake first calls the function defined by the - BB_HASHCHECK_FUNCTION + BB_HASHCHECK_FUNCTION variable with a list of tasks and corresponding hashes it wants to build. This function is designed to be fast and returns a list @@ -908,7 +908,7 @@ For example, it is pointless to obtain a compiler if you already have the compiled binary. To handle this, BitBake calls the - BB_SETSCENE_DEPVALID + BB_SETSCENE_DEPVALID function for each successful setscene task to know whether or not it needs to obtain the dependencies of that task. @@ -916,7 +916,7 @@ Finally, after all the setscene tasks have executed, BitBake calls the function listed in - BB_SETSCENE_VERIFY_FUNCTION2 + BB_SETSCENE_VERIFY_FUNCTION2 with the list of tasks BitBake thinks has been "covered". The metadata can then ensure that this list is correct and can inform BitBake that it wants specific tasks to be run regardless -- cgit v1.2.3-54-g00ecf