summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
Diffstat
-rw-r--r--documentation/overview-manual/overview-concepts.xml368
-rw-r--r--documentation/ref-manual/ref-variables.xml5
-rw-r--r--documentation/ref-manual/technical-details.xml222
-rw-r--r--documentation/yocto-project-qs/qs.xml5
4 files changed, 314 insertions, 286 deletions
diff --git a/documentation/overview-manual/overview-concepts.xml b/documentation/overview-manual/overview-concepts.xml
index dea30bc907..aa8d35e3f9 100644
--- a/documentation/overview-manual/overview-concepts.xml
+++ b/documentation/overview-manual/overview-concepts.xml
@@ -6,72 +6,320 @@
6<title>Yocto Project Concepts</title> 6<title>Yocto Project Concepts</title>
7 7
8 <para> 8 <para>
9 This chapter presents key Yocto Project concepts. 9 This chapter describes concepts for various areas of the Yocto Project.
10 Currently, topics include Yocto Project components, cross-development
11 generation, shared state (sstate) cache, runtime dependencies,
12 Pseudo and Fakeroot, x32 psABI, Wayland support, and Licenses.
10 </para> 13 </para>
11 14
12<section id='x32'> 15 <section id='yocto-project-components'>
13 <title>x32 psABI</title> 16 <title>Yocto Project Components</title>
14 17
15 <para> 18 <para>
16 x32 processor-specific Application Binary Interface 19 The
17 (<ulink url='https://software.intel.com/en-us/node/628948'>x32 psABI</ulink>) 20 <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink>
18 is a native 32-bit processor-specific ABI for 21 task executor together with various types of configuration files
19 <trademark class='registered'>Intel</trademark> 64 (x86-64) 22 form the OpenEmbedded Core.
20 architectures. 23 This section overviews these components by describing their use and
21 An ABI defines the calling conventions between functions in a 24 how they interact.
22 processing environment. 25 </para>
23 The interface determines what registers are used and what the sizes are
24 for various C data types.
25 </para>
26 26
27 <para> 27 <para>
28 Some processing environments prefer using 32-bit applications even when 28 BitBake handles the parsing and execution of the data files.
29 running on Intel 64-bit platforms. 29 The data itself is of various types:
30 Consider the i386 psABI, which is a very old 32-bit ABI for Intel 30 <itemizedlist>
31 64-bit platforms. 31 <listitem><para>
32 The i386 psABI does not provide efficient use and access of the 32 <emphasis>Recipes:</emphasis>
33 Intel 64-bit processor resources, leaving the system underutilized. 33 Provides details about particular pieces of software.
34 Now consider the x86_64 psABI. 34 </para></listitem>
35 This ABI is newer and uses 64-bits for data sizes and program pointers. 35 <listitem><para>
36 The extra bits increase the footprint size of the programs, libraries, 36 <emphasis>Class Data:</emphasis>
37 and also increases the memory and file system size requirements. 37 Abstracts common build information (e.g. how to build a
38 Executing under the x32 psABI enables user programs to utilize CPU 38 Linux kernel).
39 and system resources more efficiently while keeping the memory 39 </para></listitem>
40 footprint of the applications low. 40 <listitem><para>
41 Extra bits are used for registers but not for addressing mechanisms. 41 <emphasis>Configuration Data:</emphasis>
42 </para> 42 Defines machine-specific settings, policy decisions, and
43 so forth.
44 Configuration data acts as the glue to bind everything
45 together.
46 </para></listitem>
47 </itemizedlist>
48 </para>
43 49
44 <para> 50 <para>
45 The Yocto Project supports the final specifications of x32 psABI 51 BitBake knows how to combine multiple data sources together and
46 as follows: 52 refers to each data source as a layer.
47 <itemizedlist> 53 For information on layers, see the
48 <listitem><para> 54 "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
49 You can create packages and images in x32 psABI format on 55 section of the Yocto Project Development Tasks Manual.
50 x86_64 architecture targets. 56 </para>
51 </para></listitem>
52 <listitem><para>
53 You can successfully build recipes with the x32 toolchain.
54 </para></listitem>
55 <listitem><para>
56 You can create and boot
57 <filename>core-image-minimal</filename> and
58 <filename>core-image-sato</filename> images.
59 </para></listitem>
60 <listitem><para>
61 RPM Package Manager (RPM) support exists for x32 binaries.
62 </para></listitem>
63 <listitem><para>
64 Support for large images exists.
65 </para></listitem>
66 </itemizedlist>
67 </para>
68 57
69 <para> 58 <para>
70 For steps on how to use x32 psABI, see the 59 Following are some brief details on these core components.
71 "<ulink url='&YOCTO_DOCS_DEV_URL;#using-x32-psabi'>Using x32 psABI</ulink>" 60 For additional information on how these components interact during
72 section in the Yocto Project Development Tasks Manual. 61 a build, see the
73 </para> 62 "<link linkend='development-concepts'>Development Concepts</link>"
74</section> 63 section.
64 </para>
65
66 <section id='usingpoky-components-bitbake'>
67 <title>BitBake</title>
68
69 <para>
70 BitBake is the tool at the heart of the OpenEmbedded build
71 system and is responsible for parsing the
72 <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>,
73 generating a list of tasks from it, and then executing those
74 tasks.
75 </para>
76
77 <para>
78 This section briefly introduces BitBake.
79 If you want more information on BitBake, see the
80 <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual'>BitBake User Manual</ulink>.
81 </para>
82
83 <para>
84 To see a list of the options BitBake supports, use either of
85 the following commands:
86 <literallayout class='monospaced'>
87 $ bitbake -h
88 $ bitbake --help
89 </literallayout>
90 </para>
91
92 <para>
93 The most common usage for BitBake is
94 <filename>bitbake <replaceable>packagename</replaceable></filename>,
95 where <filename>packagename</filename> is the name of the
96 package you want to build (referred to as the "target" in this
97 manual).
98 The target often equates to the first part of a recipe's
99 filename (e.g. "foo" for a recipe named
100 <filename>foo_1.3.0-r0.bb</filename>).
101 So, to process the
102 <filename>matchbox-desktop_1.2.3.bb</filename> recipe file, you
103 might type the following:
104 <literallayout class='monospaced'>
105 $ bitbake matchbox-desktop
106 </literallayout>
107 Several different versions of
108 <filename>matchbox-desktop</filename> might exist.
109 BitBake chooses the one selected by the distribution
110 configuration.
111 You can get more details about how BitBake chooses between
112 different target versions and providers in the
113 "<ulink url='&YOCTO_DOCS_BB_URL;#bb-bitbake-preferences'>Preferences</ulink>"
114 section of the BitBake User Manual.
115 </para>
116
117 <para>
118 BitBake also tries to execute any dependent tasks first.
119 So for example, before building
120 <filename>matchbox-desktop</filename>, BitBake would build a
121 cross compiler and <filename>glibc</filename> if they had not
122 already been built.
123 </para>
124
125 <para>
126 A useful BitBake option to consider is the
127 <filename>-k</filename> or <filename>--continue</filename>
128 option.
129 This option instructs BitBake to try and continue processing
130 the job as long as possible even after encountering an error.
131 When an error occurs, the target that failed and those that
132 depend on it cannot be remade.
133 However, when you use this option other dependencies can
134 still be processed.
135 </para>
136 </section>
137
138 <section id='usingpoky-components-metadata'>
139 <title>Metadata (Recipes)</title>
140
141 <para>
142 Files that have the <filename>.bb</filename> suffix are
143 "recipes" files.
144 In general, a recipe contains information about a single piece
145 of software.
146 This information includes the location from which to download
147 the unaltered source, any source patches to be applied to that
148 source (if needed), which special configuration options to
149 apply, how to compile the source files, and how to package the
150 compiled output.
151 </para>
152
153 <para>
154 The term "package" is sometimes used to refer to recipes.
155 However, since the word "package" is used for the packaged
156 output from the OpenEmbedded build system (i.e.
157 <filename>.ipk</filename> or <filename>.deb</filename> files),
158 this document avoids using the term "package" when referring
159 to recipes.
160 </para>
161 </section>
162
163 <section id='metadata-virtual-providers'>
164 <title>Metadata (Virtual Providers)</title>
165
166 <para>
167 Prior to the build, if you know that several different recipes
168 provide the same functionality, you can use a virtual provider
169 (i.e. <filename>virtual/*</filename>) as a placeholder for the
170 actual provider.
171 The actual provider would be determined at build time.
172 In this case, you should add <filename>virtual/*</filename>
173 to
174 <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>,
175 rather than listing the specified provider.
176 You would select the actual provider by setting the
177 <ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></ulink>
178 variable (i.e.
179 <filename>PREFERRED_PROVIDER_virtual/*</filename>)
180 in the build's configuration file (e.g.
181 <filename>poky/build/conf/local.conf</filename>).
182 <note>
183 Any recipe that PROVIDES a <filename>virtual/*</filename>
184 item that is ultimately not selected through
185 <filename>PREFERRED_PROVIDER</filename> does not get built.
186 Preventing these recipes from building is usually the
187 desired behavior since this mechanism's purpose is to
188 select between mutually exclusive alternative providers.
189 </note>
190 </para>
191
192 <para>
193 The following lists specific examples of virtual providers:
194 <itemizedlist>
195 <listitem><para>
196 <filename>virtual/mesa</filename>:
197 Provides <filename>gbm.pc</filename>.
198 </para></listitem>
199 <listitem><para>
200 <filename>virtual/egl</filename>:
201 Provides <filename>egl.pc</filename> and possibly
202 <filename>wayland-egl.pc</filename>.
203 </para></listitem>
204 <listitem><para>
205 <filename>virtual/libgl</filename>:
206 Provides <filename>gl.pc</filename> (i.e. libGL).
207 </para></listitem>
208 <listitem><para>
209 <filename>virtual/libgles1</filename>:
210 Provides <filename>glesv1_cm.pc</filename>
211 (i.e. libGLESv1_CM).
212 </para></listitem>
213 <listitem><para>
214 <filename>virtual/libgles2</filename>:
215 Provides <filename>glesv2.pc</filename>
216 (i.e. libGLESv2).
217 </para></listitem>
218 </itemizedlist>
219 </para>
220 </section>
221
222 <section id='usingpoky-components-classes'>
223 <title>Classes</title>
224
225 <para>
226 Class files (<filename>.bbclass</filename>) contain information
227 that is useful to share between
228 <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
229 files.
230 An example is the
231 <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-autotools'><filename>autotools</filename></ulink>
232 class, which contains common settings for any application that
233 Autotools uses.
234 The
235 "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes'>Classes</ulink>"
236 chapter in the Yocto Project Reference Manual provides
237 details about classes and how to use them.
238 </para>
239 </section>
240
241 <section id='usingpoky-components-configuration'>
242 <title>Configuration</title>
243
244 <para>
245 The configuration files (<filename>.conf</filename>) define
246 various configuration variables that govern the OpenEmbedded
247 build process.
248 These files fall into several areas that define machine
249 configuration options, distribution configuration options,
250 compiler tuning options, general common configuration options,
251 and user configuration options in
252 <filename>local.conf</filename>, which is found in the
253 <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>.
254 </para>
255 </section>
256 </section>
257
258 <section id='x32'>
259 <title>x32 psABI</title>
260
261 <para>
262 x32 processor-specific Application Binary Interface
263 (<ulink url='https://software.intel.com/en-us/node/628948'>x32 psABI</ulink>)
264 is a native 32-bit processor-specific ABI for
265 <trademark class='registered'>Intel</trademark> 64 (x86-64)
266 architectures.
267 An ABI defines the calling conventions between functions in a
268 processing environment.
269 The interface determines what registers are used and what the sizes are
270 for various C data types.
271 </para>
272
273 <para>
274 Some processing environments prefer using 32-bit applications even
275 when running on Intel 64-bit platforms.
276 Consider the i386 psABI, which is a very old 32-bit ABI for Intel
277 64-bit platforms.
278 The i386 psABI does not provide efficient use and access of the
279 Intel 64-bit processor resources, leaving the system underutilized.
280 Now consider the x86_64 psABI.
281 This ABI is newer and uses 64-bits for data sizes and program
282 pointers.
283 The extra bits increase the footprint size of the programs,
284 libraries, and also increases the memory and file system size
285 requirements.
286 Executing under the x32 psABI enables user programs to utilize CPU
287 and system resources more efficiently while keeping the memory
288 footprint of the applications low.
289 Extra bits are used for registers but not for addressing mechanisms.
290 </para>
291
292 <para>
293 The Yocto Project supports the final specifications of x32 psABI
294 as follows:
295 <itemizedlist>
296 <listitem><para>
297 You can create packages and images in x32 psABI format on
298 x86_64 architecture targets.
299 </para></listitem>
300 <listitem><para>
301 You can successfully build recipes with the x32 toolchain.
302 </para></listitem>
303 <listitem><para>
304 You can create and boot
305 <filename>core-image-minimal</filename> and
306 <filename>core-image-sato</filename> images.
307 </para></listitem>
308 <listitem><para>
309 RPM Package Manager (RPM) support exists for x32 binaries.
310 </para></listitem>
311 <listitem><para>
312 Support for large images exists.
313 </para></listitem>
314 </itemizedlist>
315 </para>
316
317 <para>
318 For steps on how to use x32 psABI, see the
319 "<ulink url='&YOCTO_DOCS_DEV_URL;#using-x32-psabi'>Using x32 psABI</ulink>"
320 section in the Yocto Project Development Tasks Manual.
321 </para>
322 </section>
75</chapter> 323</chapter>
76<!-- 324<!--
77vim: expandtab tw=80 ts=4 325vim: expandtab tw=80 ts=4
diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index 251e10c83f..1b5f863970 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -10709,8 +10709,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
10709 PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86" 10709 PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
10710 PREFERRED_PROVIDER_virtual/libgl ?= "mesa" 10710 PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
10711 </literallayout> 10711 </literallayout>
10712 For more information see: 10712 For more information, see the
10713 <link linkend='metadata-virtual-providers'>Metadata (Virtual Providers)</link> 10713 "<ulink url='&YOCTO_DOCS_OVERVIEW_URL;#metadata-virtual-providers'>Metadata (Virtual Providers)</ulink>"
10714 section in the Yocto Project Overview Manual.
10714 <note> 10715 <note>
10715 If you set <filename>PREFERRED_PROVIDER</filename> 10716 If you set <filename>PREFERRED_PROVIDER</filename>
10716 for a <filename>virtual/*</filename> item, then any 10717 for a <filename>virtual/*</filename> item, then any
diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml
index 5769cd619a..d0929bd756 100644
--- a/documentation/ref-manual/technical-details.xml
+++ b/documentation/ref-manual/technical-details.xml
@@ -13,228 +13,6 @@
13 x32, Wayland support, and Licenses. 13 x32, Wayland support, and Licenses.
14 </para> 14 </para>
15 15
16<section id='usingpoky-components'>
17 <title>Yocto Project Components</title>
18
19 <para>
20 The
21 <link linkend='bitbake-term'>BitBake</link>
22 task executor together with various types of configuration files form
23 the OpenEmbedded Core.
24 This section overviews these components by describing their use and
25 how they interact.
26 </para>
27
28 <para>
29 BitBake handles the parsing and execution of the data files.
30 The data itself is of various types:
31 <itemizedlist>
32 <listitem><para><emphasis>Recipes:</emphasis> Provides details
33 about particular pieces of software.
34 </para></listitem>
35 <listitem><para><emphasis>Class Data:</emphasis> Abstracts
36 common build information (e.g. how to build a Linux kernel).
37 </para></listitem>
38 <listitem><para><emphasis>Configuration Data:</emphasis> Defines
39 machine-specific settings, policy decisions, and so forth.
40 Configuration data acts as the glue to bind everything
41 together.
42 </para></listitem>
43 </itemizedlist>
44 </para>
45
46 <para>
47 BitBake knows how to combine multiple data sources together and refers
48 to each data source as a layer.
49 For information on layers, see the
50 "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and
51 Creating Layers</ulink>" section of the Yocto Project Development
52 Tasks Manual.
53 </para>
54
55 <para>
56 Following are some brief details on these core components.
57 For additional information on how these components interact during
58 a build, see the
59 "<ulink url='&YOCTO_DOCS_OVERVIEW_URL;#development-concepts'>Development Concepts</ulink>"
60 section in the Yocto Project Overview Manual.
61 </para>
62
63 <section id='usingpoky-components-bitbake'>
64 <title>BitBake</title>
65
66 <para>
67 BitBake is the tool at the heart of the OpenEmbedded build system
68 and is responsible for parsing the
69 <link linkend='metadata'>Metadata</link>,
70 generating a list of tasks from it, and then executing those tasks.
71 </para>
72
73 <para>
74 This section briefly introduces BitBake.
75 If you want more information on BitBake, see the
76 <ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual'>BitBake User Manual</ulink>.
77 </para>
78
79 <para>
80 To see a list of the options BitBake supports, use either of
81 the following commands:
82 <literallayout class='monospaced'>
83 $ bitbake -h
84 $ bitbake --help
85 </literallayout>
86 </para>
87
88 <para>
89 The most common usage for BitBake is <filename>bitbake <replaceable>packagename</replaceable></filename>, where
90 <filename>packagename</filename> is the name of the package you want to build
91 (referred to as the "target" in this manual).
92 The target often equates to the first part of a recipe's filename
93 (e.g. "foo" for a recipe named
94 <filename>foo_1.3.0-r0.bb</filename>).
95 So, to process the <filename>matchbox-desktop_1.2.3.bb</filename> recipe file, you
96 might type the following:
97 <literallayout class='monospaced'>
98 $ bitbake matchbox-desktop
99 </literallayout>
100 Several different versions of <filename>matchbox-desktop</filename> might exist.
101 BitBake chooses the one selected by the distribution configuration.
102 You can get more details about how BitBake chooses between different
103 target versions and providers in the
104 "<ulink url='&YOCTO_DOCS_BB_URL;#bb-bitbake-preferences'>Preferences</ulink>"
105 section of the BitBake User Manual.
106 </para>
107
108 <para>
109 BitBake also tries to execute any dependent tasks first.
110 So for example, before building <filename>matchbox-desktop</filename>, BitBake
111 would build a cross compiler and <filename>glibc</filename> if they had not already
112 been built.
113 </para>
114
115 <para>
116 A useful BitBake option to consider is the <filename>-k</filename> or
117 <filename>--continue</filename> option.
118 This option instructs BitBake to try and continue processing the job
119 as long as possible even after encountering an error.
120 When an error occurs, the target that
121 failed and those that depend on it cannot be remade.
122 However, when you use this option other dependencies can still be
123 processed.
124 </para>
125 </section>
126
127 <section id='usingpoky-components-metadata'>
128 <title>Metadata (Recipes)</title>
129
130 <para>
131 Files that have the <filename>.bb</filename> suffix are "recipes"
132 files.
133 In general, a recipe contains information about a single piece of
134 software.
135 This information includes the location from which to download the
136 unaltered source, any source patches to be applied to that source
137 (if needed), which special configuration options to apply,
138 how to compile the source files, and how to package the compiled
139 output.
140 </para>
141
142 <para>
143 The term "package" is sometimes used to refer to recipes. However,
144 since the word "package" is used for the packaged output from the OpenEmbedded
145 build system (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files),
146 this document avoids using the term "package" when referring to recipes.
147 </para>
148 </section>
149
150 <section id='metadata-virtual-providers'>
151 <title>Metadata (Virtual Providers)</title>
152
153 <para>
154 Prior to the build, if you know that several different recipes
155 provide the same functionality, you can use a virtual provider
156 (i.e. <filename>virtual/*</filename>) as a placeholder for the
157 actual provider.
158 The actual provider would be determined at build
159 time.
160 In this case, you should add <filename>virtual/*</filename>
161 to <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>,
162 rather than listing the specified provider.
163 You would select the actual provider by setting the
164 <link linkend='var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></link>
165 variable (i.e. <filename>PREFERRED_PROVIDER_virtual/*</filename>)
166 in the build's configuration file (e.g.
167 <filename>poky/build/conf/local.conf</filename>).
168 <note>
169 Any recipe that PROVIDES a <filename>virtual/*</filename> item
170 that is ultimately not selected through
171 <filename>PREFERRED_PROVIDER</filename> does not get built.
172 Preventing these recipes from building is usually the desired
173 behavior since this mechanism's purpose is to select between
174 mutually exclusive alternative providers.
175 </note>
176 </para>
177
178 <para>
179 The following lists specific examples of virtual providers:
180 <itemizedlist>
181 <listitem><para>
182 <filename>virtual/mesa</filename>:
183 Provides <filename>gbm.pc</filename>.
184 </para></listitem>
185 <listitem><para>
186 <filename>virtual/egl</filename>:
187 Provides <filename>egl.pc</filename> and possibly
188 <filename>wayland-egl.pc</filename>.
189 </para></listitem>
190 <listitem><para>
191 <filename>virtual/libgl</filename>:
192 Provides <filename>gl.pc</filename> (i.e. libGL).
193 </para></listitem>
194 <listitem><para>
195 <filename>virtual/libgles1</filename>:
196 Provides <filename>glesv1_cm.pc</filename>
197 (i.e. libGLESv1_CM).
198 </para></listitem>
199 <listitem><para>
200 <filename>virtual/libgles2</filename>:
201 Provides <filename>glesv2.pc</filename> (i.e. libGLESv2).
202 </para></listitem>
203 </itemizedlist>
204 </para>
205 </section>
206
207 <section id='usingpoky-components-classes'>
208 <title>Classes</title>
209
210 <para>
211 Class files (<filename>.bbclass</filename>) contain information that
212 is useful to share between
213 <link linkend='metadata'>Metadata</link> files.
214 An example is the
215 <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
216 class, which contains common settings for any application that
217 Autotools uses.
218 The "<link linkend='ref-classes'>Classes</link>" chapter provides
219 details about classes and how to use them.
220 </para>
221 </section>
222
223 <section id='usingpoky-components-configuration'>
224 <title>Configuration</title>
225
226 <para>
227 The configuration files (<filename>.conf</filename>) define various configuration variables
228 that govern the OpenEmbedded build process.
229 These files fall into several areas that define machine configuration options,
230 distribution configuration options, compiler tuning options, general common configuration
231 options, and user configuration options in <filename>local.conf</filename>, which is found
232 in the
233 <link linkend='build-directory'>Build Directory</link>.
234 </para>
235 </section>
236</section>
237
238<section id="cross-development-toolchain-generation"> 16<section id="cross-development-toolchain-generation">
239 <title>Cross-Development Toolchain Generation</title> 17 <title>Cross-Development Toolchain Generation</title>
240 18
diff --git a/documentation/yocto-project-qs/qs.xml b/documentation/yocto-project-qs/qs.xml
index 69ed96f41f..be3a2a603f 100644
--- a/documentation/yocto-project-qs/qs.xml
+++ b/documentation/yocto-project-qs/qs.xml
@@ -611,8 +611,9 @@
611 </note> 611 </note>
612 For information on using the 612 For information on using the
613 <filename>bitbake</filename> command, see the 613 <filename>bitbake</filename> command, see the
614 "<ulink url='&YOCTO_DOCS_REF_URL;#usingpoky-components-bitbake'>BitBake</ulink>" 614 "<ulink url='&YOCTO_DOCS_OVERVIEW_URL;#usingpoky-components-bitbake'>BitBake</ulink>"
615 section in the Yocto Project Reference Manual, or see the 615 section in the Yocto Project Overview Manual, or
616 see the
616 "<ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual-command'>BitBake Command</ulink>" 617 "<ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual-command'>BitBake Command</ulink>"
617 section in the BitBake User Manual. 618 section in the BitBake User Manual.
618 For information on other targets, see the 619 For information on other targets, see the
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-14 20:09:51 +0000