mirror of
git://git.yoctoproject.org/poky
synced 2026-05-19 00:41:06 +00:00
ae06e04cd2
Creation involved removing the overview-manual and replacing it with the getting-started manual. All links to the string "&YOCTO_DOCS_OVERVIEW_URL" had to be replaced with "&YOCTO_DOCS_GS_URL" across the entire YP manual set. I renamed files used to create the manual with prefixes suited for the new manual name, which is "Getting Started With Yocto Project". The style sheet for the new manual needed updating to display the new .PNG image for the title page. The mega-manual file had to be updated to include the files. The mega-manual.sed file had to be updated to include the new manual and not use the overview manual. (From yocto-docs rev: 6c7abf9192390121000f577d6c98f259d290d15d) Signed-off-by: Scott Rifenbark <srifenbark@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
123 lines
7.4 KiB
HTML
123 lines
7.4 KiB
HTML
<html>
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||
<title>2.8.5.8. Setscene Tasks and Shared State</title>
|
||
<link rel="stylesheet" type="text/css" href="../book.css">
|
||
<meta name="generator" content="DocBook XSL Stylesheets V1.76.1">
|
||
<link rel="home" href="index.html" title="Getting Started With Yocto Project">
|
||
<link rel="up" href="bitbake-dev-environment.html" title="2.8.5. BitBake">
|
||
<link rel="prev" href="stamp-files-and-the-rerunning-of-tasks.html" title="2.8.5.7. Stamp Files and the Rerunning of Tasks">
|
||
<link rel="next" href="images-dev-environment.html" title="2.8.6. Images">
|
||
</head>
|
||
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="2.8.5.8. Setscene Tasks and Shared State">
|
||
<div class="titlepage"><div><div><h4 class="title">
|
||
<a name="setscene-tasks-and-shared-state"></a>2.8.5.8. Setscene Tasks and Shared State</h4></div></div></div>
|
||
<p>
|
||
The description of tasks so far assumes that BitBake needs to
|
||
build everything and there are no prebuilt objects available.
|
||
BitBake does support skipping tasks if prebuilt objects are
|
||
available.
|
||
These objects are usually made available in the form of a
|
||
shared state (sstate) cache.
|
||
</p>
|
||
<div class="note" title="Note" style="margin-left: 0.5in; margin-right: 0.5in;">
|
||
<h3 class="title">Note</h3>
|
||
For information on variables affecting sstate, see the
|
||
<a class="link" href="../ref-manual/var-SSTATE_DIR.html" target="_self"><code class="filename">SSTATE_DIR</code></a>
|
||
and
|
||
<a class="link" href="../ref-manual/var-SSTATE_MIRRORS.html" target="_self"><code class="filename">SSTATE_MIRRORS</code></a>
|
||
variables.
|
||
</div>
|
||
<p>
|
||
</p>
|
||
<p>
|
||
The idea of a setscene task (i.e
|
||
<code class="filename">do_</code><em class="replaceable"><code>taskname</code></em><code class="filename">_setscene</code>)
|
||
is a version of the task where
|
||
instead of building something, BitBake can skip to the end
|
||
result and simply place a set of files into specific locations
|
||
as needed.
|
||
In some cases, it makes sense to have a setscene task variant
|
||
(e.g. generating package files in the
|
||
<code class="filename">do_package_write_*</code> task).
|
||
In other cases, it does not make sense, (e.g. a
|
||
<a class="link" href="../ref-manual/ref-tasks-patch.html" target="_self"><code class="filename">do_patch</code></a>
|
||
task or
|
||
<a class="link" href="../ref-manual/ref-tasks-unpack.html" target="_self"><code class="filename">do_unpack</code></a>
|
||
task) since the work involved would be equal to or greater than
|
||
the underlying task.
|
||
</p>
|
||
<p>
|
||
In the OpenEmbedded build system, the common tasks that have
|
||
setscene variants are
|
||
<a class="link" href="../ref-manual/ref-tasks-package.html" target="_self"><code class="filename">do_package</code></a>,
|
||
<code class="filename">do_package_write_*</code>,
|
||
<a class="link" href="../ref-manual/ref-tasks-deploy.html" target="_self"><code class="filename">do_deploy</code></a>,
|
||
<a class="link" href="../ref-manual/ref-tasks-packagedata.html" target="_self"><code class="filename">do_packagedata</code></a>,
|
||
and
|
||
<a class="link" href="../ref-manual/ref-tasks-populate_sysroot.html" target="_self"><code class="filename">do_populate_sysroot</code></a>.
|
||
Notice that these are most of the tasks whose output is an
|
||
end result.
|
||
</p>
|
||
<p>
|
||
The OpenEmbedded build system has knowledge of the relationship
|
||
between these tasks and other tasks that precede them.
|
||
For example, if BitBake runs
|
||
<code class="filename">do_populate_sysroot_setscene</code> for
|
||
something, there is little point in running any of the
|
||
<code class="filename">do_fetch</code>, <code class="filename">do_unpack</code>,
|
||
<code class="filename">do_patch</code>,
|
||
<code class="filename">do_configure</code>,
|
||
<code class="filename">do_compile</code>, and
|
||
<code class="filename">do_install</code> tasks.
|
||
However, if <code class="filename">do_package</code> needs to be run,
|
||
BitBake would need to run those other tasks.
|
||
</p>
|
||
<p>
|
||
It becomes more complicated if everything can come from an
|
||
sstate cache because some objects are simply not required at
|
||
all.
|
||
For example, you do not need a compiler or native tools, such
|
||
as quilt, if there is nothing to compile or patch.
|
||
If the <code class="filename">do_package_write_*</code> packages are
|
||
available from sstate, BitBake does not need the
|
||
<code class="filename">do_package</code> task data.
|
||
</p>
|
||
<p>
|
||
To handle all these complexities, BitBake runs in two phases.
|
||
The first is the "setscene" stage.
|
||
During this stage, BitBake first checks the sstate cache for
|
||
any targets it is planning to build.
|
||
BitBake does a fast check to see if the object exists rather
|
||
than a complete download.
|
||
If nothing exists, the second phase, which is the setscene
|
||
stage, completes and the main build proceeds.
|
||
</p>
|
||
<p>
|
||
If objects are found in the sstate cache, the OpenEmbedded
|
||
build system works backwards from the end targets specified
|
||
by the user.
|
||
For example, if an image is being built, the OpenEmbedded build
|
||
system first looks for the packages needed for that image and
|
||
the tools needed to construct an image.
|
||
If those are available, the compiler is not needed.
|
||
Thus, the compiler is not even downloaded.
|
||
If something was found to be unavailable, or the download or
|
||
setscene task fails, the OpenEmbedded build system then tries
|
||
to install dependencies, such as the compiler, from the cache.
|
||
</p>
|
||
<p>
|
||
The availability of objects in the sstate cache is handled by
|
||
the function specified by the
|
||
<a class="link" href="../bitbake-user-manual/var-BB_HASHCHECK_FUNCTION.html" target="_self"><code class="filename">BB_HASHCHECK_FUNCTION</code></a>
|
||
variable and returns a list of the objects that are available.
|
||
The function specified by the
|
||
<a class="link" href="../bitbake-user-manual/var-BB_SETSCENE_DEPVALID.html" target="_self"><code class="filename">BB_SETSCENE_DEPVALID</code></a>
|
||
variable is the function that determines whether a given
|
||
dependency needs to be followed, and whether for any given
|
||
relationship the function needs to be passed.
|
||
The function returns a True or False value.
|
||
</p>
|
||
</div></body>
|
||
</html>
|