32 lines
1.9 KiB
HTML
32 lines
1.9 KiB
HTML
<html>
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||
<title>3.2.1. Overall Architecture</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="The Yocto Project Reference Manual">
|
||
<link rel="up" href="shared-state-cache.html" title="3.2. Shared State Cache">
|
||
<link rel="prev" href="shared-state-cache.html" title="3.2. Shared State Cache">
|
||
<link rel="next" href="checksums.html" title="3.2.2. Checksums (Signatures)">
|
||
</head>
|
||
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="section" title="3.2.1. Overall Architecture">
|
||
<div class="titlepage"><div><div><h3 class="title">
|
||
<a name="overall-architecture"></a>3.2.1. Overall Architecture</h3></div></div></div>
|
||
<p>
|
||
When determining what parts of the system need to be built, BitBake
|
||
uses a per-task basis and does not use a per-recipe basis.
|
||
You might wonder why using a per-task basis is preferred over a per-recipe basis.
|
||
To help explain, consider having the IPK packaging backend enabled and then switching to DEB.
|
||
In this case, <code class="filename">do_install</code> and <code class="filename">do_package</code>
|
||
output are still valid.
|
||
However, with a per-recipe approach, the build would not include the
|
||
<code class="filename">.deb</code> files.
|
||
Consequently, you would have to invalidate the whole build and rerun it.
|
||
Rerunning everything is not the best situation.
|
||
Also in this case, the core must be "taught" much about specific tasks.
|
||
This methodology does not scale well and does not allow users to easily add new tasks
|
||
in layers or as external recipes without touching the packaged-staging core.
|
||
</p>
|
||
</div></body>
|
||
</html>
|