summaryrefslogtreecommitdiffstats
path: root/documentation/ref-manual/faq.xml
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/ref-manual/faq.xml')
-rw-r--r--documentation/ref-manual/faq.xml698
1 files changed, 698 insertions, 0 deletions
diff --git a/documentation/ref-manual/faq.xml b/documentation/ref-manual/faq.xml
new file mode 100644
index 0000000..c7ccaaf
--- /dev/null
+++ b/documentation/ref-manual/faq.xml
@@ -0,0 +1,698 @@
1<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
2"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
3[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
4
5<chapter id='faq'>
6<title>FAQ</title>
7<qandaset>
8 <qandaentry>
9 <question>
10 <para>
11 How does Poky differ from <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>?
12 </para>
13 </question>
14 <answer>
15 <para>
16 The term "<ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>"
17 refers to the specific reference build system that
18 the Yocto Project provides.
19 Poky is based on <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink>
20 and <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>.
21 Thus, the generic term used here for the build system is
22 the "OpenEmbedded build system."
23 Development in the Yocto Project using Poky is closely tied to OpenEmbedded, with
24 changes always being merged to OE-Core or BitBake first before being pulled back
25 into Poky.
26 This practice benefits both projects immediately.
27 </para>
28 </answer>
29 </qandaentry>
30
31 <qandaentry>
32 <question>
33 <para>
34 My development system does not have Python 2.7.3 or greater,
35 which the Yocto Project requires.
36 Can I still use the Yocto Project?
37 </para>
38 </question>
39 <answer>
40 <para>
41 You can get the required tools on your host development
42 system a couple different ways (i.e. building a tarball or
43 downloading a tarball).
44 See the
45 "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>"
46 section for steps on how to update your build tools.
47 </para>
48 </answer>
49 </qandaentry>
50
51 <qandaentry>
52 <question>
53 <para>
54 How can you claim Poky / OpenEmbedded-Core is stable?
55 </para>
56 </question>
57 <answer>
58 <para>
59 There are three areas that help with stability;
60 <itemizedlist>
61 <listitem><para>The Yocto Project team keeps
62 <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink> small
63 and focused, containing around 830 recipes as opposed to the thousands
64 available in other OpenEmbedded community layers.
65 Keeping it small makes it easy to test and maintain.</para></listitem>
66 <listitem><para>The Yocto Project team runs manual and automated tests
67 using a small, fixed set of reference hardware as well as emulated
68 targets.</para></listitem>
69 <listitem><para>The Yocto Project uses an autobuilder,
70 which provides continuous build and integration tests.</para></listitem>
71 </itemizedlist>
72 </para>
73 </answer>
74 </qandaentry>
75
76 <qandaentry>
77 <question>
78 <para>
79 How do I get support for my board added to the Yocto Project?
80 </para>
81 </question>
82 <answer>
83 <para>
84 Support for an additional board is added by creating a
85 Board Support Package (BSP) layer for it.
86 For more information on how to create a BSP layer, see the
87 "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
88 section in the Yocto Project Development Manual and the
89 <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
90 </para>
91 <para>
92 Usually, if the board is not completely exotic, adding support in
93 the Yocto Project is fairly straightforward.
94 </para>
95 </answer>
96 </qandaentry>
97
98 <qandaentry>
99 <question>
100 <para>
101 Are there any products built using the OpenEmbedded build system?
102 </para>
103 </question>
104 <answer>
105 <para>
106 The software running on the <ulink url='http://vernier.com/labquest/'>Vernier LabQuest</ulink>
107 is built using the OpenEmbedded build system.
108 See the <ulink url='http://www.vernier.com/products/interfaces/labq/'>Vernier LabQuest</ulink>
109 website for more information.
110 There are a number of pre-production devices using the OpenEmbedded build system
111 and the Yocto Project team
112 announces them as soon as they are released.
113 </para>
114 </answer>
115 </qandaentry>
116
117 <qandaentry>
118 <question>
119 <para>
120 What does the OpenEmbedded build system produce as output?
121 </para>
122 </question>
123 <answer>
124 <para>
125 Because you can use the same set of recipes to create output of
126 various formats, the output of an OpenEmbedded build depends on
127 how you start it.
128 Usually, the output is a flashable image ready for the target
129 device.
130 </para>
131 </answer>
132 </qandaentry>
133
134 <qandaentry>
135 <question>
136 <para>
137 How do I add my package to the Yocto Project?
138 </para>
139 </question>
140 <answer>
141 <para>
142 To add a package, you need to create a BitBake recipe.
143 For information on how to add a package, see the section
144 "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-addpkg'>Writing a Recipe to Add a Package to Your Image</ulink>"
145 in the Yocto Project Development Manual.
146 </para>
147 </answer>
148 </qandaentry>
149
150 <qandaentry>
151 <question>
152 <para>
153 Do I have to reflash my entire board with a new Yocto Project image when recompiling
154 a package?
155 </para>
156 </question>
157 <answer>
158 <para>
159 The OpenEmbedded build system can build packages in various
160 formats such as IPK for OPKG, Debian package
161 (<filename>.deb</filename>), or RPM.
162 You can then upgrade the packages using the package tools on
163 the device, much like on a desktop distribution such as
164 Ubuntu or Fedora.
165 However, package management on the target is entirely optional.
166 </para>
167 </answer>
168 </qandaentry>
169
170 <qandaentry>
171 <question>
172 <para>
173 What is GNOME Mobile and what is the difference between GNOME Mobile and GNOME?
174 </para>
175 </question>
176 <answer>
177 <para>
178 GNOME Mobile is a subset of the <ulink url='http://www.gnome.org'>GNOME</ulink>
179 platform targeted at mobile and embedded devices.
180 The main difference between GNOME Mobile and standard GNOME is that
181 desktop-orientated libraries have been removed, along with deprecated libraries,
182 creating a much smaller footprint.
183 </para>
184 </answer>
185 </qandaentry>
186
187 <qandaentry>
188 <question>
189 <para>
190 I see the error '<filename>chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x</filename>'.
191 What is wrong?
192 </para>
193 </question>
194 <answer>
195 <para>
196 You are probably running the build on an NTFS filesystem.
197 Use <filename>ext2</filename>, <filename>ext3</filename>, or <filename>ext4</filename> instead.
198 </para>
199 </answer>
200 </qandaentry>
201
202<!-- <qandaentry>
203 <question>
204 <para>
205 How do I make the Yocto Project work in RHEL/CentOS?
206 </para>
207 </question>
208 <answer>
209 <para>
210 To get the Yocto Project working under RHEL/CentOS 5.1 you need to first
211 install some required packages.
212 The standard CentOS packages needed are:
213 <itemizedlist>
214 <listitem><para>"Development tools" (selected during installation)</para></listitem>
215 <listitem><para><filename>texi2html</filename></para></listitem>
216 <listitem><para><filename>compat-gcc-34</filename></para></listitem>
217 </itemizedlist>
218 On top of these, you need the following external packages:
219 <itemizedlist>
220 <listitem><para><filename>python-sqlite2</filename> from
221 <ulink url='http://dag.wieers.com/rpm/packages/python-sqlite2/'>DAG repository</ulink>
222 </para></listitem>
223 <listitem><para><filename>help2man</filename> from
224 <ulink url='http://centos.karan.org/el4/extras/stable/x86_64/RPMS/repodata/repoview/help2man-0-1.33.1-2.html'>Karan repository</ulink></para></listitem>
225 </itemizedlist>
226 </para>
227
228 <para>
229 Once these packages are installed, the OpenEmbedded build system will be able
230 to build standard images.
231 However, there might be a problem with the QEMU emulator segfaulting.
232 You can either disable the generation of binary locales by setting
233 <filename><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>ENABLE_BINARY_LOCALE_GENERATION</link>
234 </filename> to "0" or by removing the <filename>linux-2.6-execshield.patch</filename>
235 from the kernel and rebuilding it since that is the patch that causes the problems with QEMU.
236 </para>
237
238 <note>
239 <para>For information on distributions that the Yocto Project
240 uses during validation, see the
241 <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink>
242 Wiki page.</para>
243 <para>For notes about using the Yocto Project on a RHEL 4-based
244 host, see the
245 <ulink url='&YOCTO_WIKI_URL;/wiki/BuildingOnRHEL4'>Building on RHEL4</ulink>
246 Wiki page.</para>
247 </note>
248 </answer>
249 </qandaentry> -->
250
251 <qandaentry>
252 <question>
253 <para>
254 I see lots of 404 responses for files on
255 <filename>&YOCTO_HOME_URL;/sources/*</filename>. Is something wrong?
256 </para>
257 </question>
258 <answer>
259 <para>
260 Nothing is wrong.
261 The OpenEmbedded build system checks any configured source mirrors before downloading
262 from the upstream sources.
263 The build system does this searching for both source archives and
264 pre-checked out versions of SCM-managed software.
265 These checks help in large installations because it can reduce load on the SCM servers
266 themselves.
267 The address above is one of the default mirrors configured into the
268 build system.
269 Consequently, if an upstream source disappears, the team
270 can place sources there so builds continue to work.
271 </para>
272 </answer>
273 </qandaentry>
274
275 <qandaentry>
276 <question>
277 <para>
278 I have machine-specific data in a package for one machine only but the package is
279 being marked as machine-specific in all cases, how do I prevent this?
280 </para>
281 </question>
282 <answer>
283 <para>
284 Set <filename><link linkend='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'>SRC_URI_OVERRIDES_PACKAGE_ARCH</link>
285 </filename> = "0" in the <filename>.bb</filename> file but make sure the package is
286 manually marked as
287 machine-specific for the case that needs it.
288 The code that handles
289 <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in
290 the <filename>meta/classes/base.bbclass</filename> file.
291 </para>
292 </answer>
293 </qandaentry>
294
295 <qandaentry>
296 <question>
297 <para>
298 I'm behind a firewall and need to use a proxy server. How do I do that?
299 </para>
300 </question>
301 <answer>
302 <para>
303 Most source fetching by the OpenEmbedded build system is done by <filename>wget</filename>
304 and you therefore need to specify the proxy settings in a
305 <filename>.wgetrc</filename> file in your home directory.
306 Here are some example settings:
307 <literallayout class='monospaced'>
308 http_proxy = http://proxy.yoyodyne.com:18023/
309 ftp_proxy = http://proxy.yoyodyne.com:18023/
310 </literallayout>
311 The Yocto Project also includes a
312 <filename>site.conf.sample</filename> file that shows how to
313 configure CVS and Git proxy servers if needed.
314 </para>
315 </answer>
316 </qandaentry>
317
318 <qandaentry>
319 <question>
320 <para>
321 What’s the difference between <filename>foo</filename> and <filename>foo-native</filename>?
322 </para>
323 </question>
324 <answer>
325 <para>
326 The <filename>*-native</filename> targets are designed to run on the system
327 being used for the build.
328 These are usually tools that are needed to assist the build in some way such as
329 <filename>quilt-native</filename>, which is used to apply patches.
330 The non-native version is the one that runs on the target device.
331 </para>
332 </answer>
333 </qandaentry>
334
335 <qandaentry>
336 <question>
337 <para>
338 I'm seeing random build failures. Help?!
339 </para>
340 </question>
341 <answer>
342 <para>
343 If the same build is failing in totally different and random
344 ways, the most likely explanation is:
345 <itemizedlist>
346 <listitem><para>The hardware you are running the build on
347 has some problem.</para></listitem>
348 <listitem><para>You are running the build under
349 virtualization, in which case the virtualization
350 probably has bugs.</para></listitem>
351 </itemizedlist>
352 The OpenEmbedded build system processes a massive amount of
353 data that causes lots of network, disk and CPU activity and
354 is sensitive to even single-bit failures in any of these areas.
355 True random failures have always been traced back to hardware
356 or virtualization issues.
357 </para>
358 </answer>
359 </qandaentry>
360
361 <qandaentry>
362 <question>
363 <para>
364 What do we need to ship for license compliance?
365 </para>
366 </question>
367 <answer>
368 <para>
369 This is a difficult question and you need to consult your lawyer
370 for the answer for your specific case.
371 It is worth bearing in mind that for GPL compliance, there needs
372 to be enough information shipped to allow someone else to
373 rebuild and produce the same end result you are shipping.
374 This means sharing the source code, any patches applied to it,
375 and also any configuration information about how that package
376 was configured and built.
377 </para>
378
379 <para>
380 You can find more information on licensing in the
381 "<ulink url='&YOCTO_DOCS_DEV_URL;#licensing'>Licensing</ulink>"
382 and "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
383 sections, both of which are in the Yocto Project Development
384 Manual.
385 </para>
386 </answer>
387 </qandaentry>
388
389 <qandaentry>
390 <question>
391 <para>
392 How do I disable the cursor on my touchscreen device?
393 </para>
394 </question>
395 <answer>
396 <para>
397 You need to create a form factor file as described in the
398 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>"
399 section in the Yocto Project Board Support Packages (BSP)
400 Developer's Guide.
401 Set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to
402 one as follows:
403 <literallayout class='monospaced'>
404 HAVE_TOUCHSCREEN=1
405 </literallayout>
406 </para>
407 </answer>
408 </qandaentry>
409
410 <qandaentry>
411 <question>
412 <para>
413 How do I make sure connected network interfaces are brought up by default?
414 </para>
415 </question>
416 <answer>
417 <para>
418 The default interfaces file provided by the netbase recipe does not
419 automatically bring up network interfaces.
420 Therefore, you will need to add a BSP-specific netbase that includes an interfaces
421 file.
422 See the "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>"
423 section in the Yocto Project Board Support Packages (BSP)
424 Developer's Guide for information on creating these types of
425 miscellaneous recipe files.
426 </para>
427 <para>
428 For example, add the following files to your layer:
429 <literallayout class='monospaced'>
430 meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
431 meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
432 </literallayout>
433 </para>
434 </answer>
435 </qandaentry>
436
437 <qandaentry>
438 <question>
439 <para>
440 How do I create images with more free space?
441 </para>
442 </question>
443 <answer>
444 <para>
445 By default, the OpenEmbedded build system creates images
446 that are 1.3 times the size of the populated root filesystem.
447 To affect the image size, you need to set various
448 configurations:
449 <itemizedlist>
450 <listitem><para><emphasis>Image Size:</emphasis>
451 The OpenEmbedded build system uses the
452 <link linkend='var-IMAGE_ROOTFS_SIZE'><filename>IMAGE_ROOTFS_SIZE</filename></link>
453 variable to define the size of the image in Kbytes.
454 The build system determines the size by taking into
455 account the initial root filesystem size before any
456 modifications such as requested size for the image and
457 any requested additional free disk space to be
458 added to the image.</para></listitem>
459 <listitem><para><emphasis>Overhead:</emphasis>
460 Use the
461 <link linkend='var-IMAGE_OVERHEAD_FACTOR'><filename>IMAGE_OVERHEAD_FACTOR</filename></link>
462 variable to define the multiplier that the build system
463 applies to the initial image size, which is 1.3 by
464 default.</para></listitem>
465 <listitem><para><emphasis>Additional Free Space:</emphasis>
466 Use the
467 <link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'><filename>IMAGE_ROOTFS_EXTRA_SPACE</filename></link>
468 variable to add additional free space to the image.
469 The build system adds this space to the image after
470 it determines its
471 <filename>IMAGE_ROOTFS_SIZE</filename>.
472 </para></listitem>
473 </itemizedlist>
474 </para>
475 </answer>
476 </qandaentry>
477
478 <qandaentry>
479 <question>
480 <para>
481 Why don't you support directories with spaces in the pathnames?
482 </para>
483 </question>
484 <answer>
485 <para>
486 The Yocto Project team has tried to do this before but too
487 many of the tools the OpenEmbedded build system depends on,
488 such as <filename>autoconf</filename>, break when they find
489 spaces in pathnames.
490 Until that situation changes, the team will not support spaces
491 in pathnames.
492 </para>
493 </answer>
494 </qandaentry>
495
496 <qandaentry>
497 <question>
498 <para>
499 How do I use an external toolchain?
500 </para>
501 </question>
502 <answer>
503 <para>
504 The toolchain configuration is very flexible and customizable.
505 It is primarily controlled with the
506 <filename><link linkend='var-TCMODE'>TCMODE</link></filename>
507 variable.
508 This variable controls which <filename>tcmode-*.inc</filename>
509 file to include from the
510 <filename>meta/conf/distro/include</filename> directory within
511 the
512 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
513 </para>
514
515 <para>
516 The default value of <filename>TCMODE</filename> is "default"
517 (i.e. <filename>tcmode-default.inc</filename>).
518 However, other patterns are accepted.
519 In particular, "external-*" refers to external toolchains of
520 which there are some basic examples included in the
521 OpenEmbedded Core (<filename>meta</filename>).
522 You can use your own custom toolchain definition in your own
523 layer (or as defined in the <filename>local.conf</filename>
524 file) at the location
525 <filename>conf/distro/include/tcmode-*.inc</filename>.
526 </para>
527
528 <para>
529 In addition to the toolchain configuration, you also need a
530 corresponding toolchain recipe file.
531 This recipe file needs to package up any pre-built objects in
532 the toolchain such as <filename>libgcc</filename>,
533 <filename>libstdcc++</filename>, any locales, and
534 <filename>libc</filename>.
535 An example is the
536 <filename>external-sourcery-toolchain.bb</filename>, which is
537 located in <filename>meta/recipes-core/meta/</filename> within
538 the Source Directory.
539 </para>
540
541 <para>
542 For information on installing and using cross-development
543 toolchains, see the
544 "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
545 section in the Yocto Project Application Developer's Guide.
546 For general information on cross-development toolchains, see
547 the
548 "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
549 section.
550 </para>
551 </answer>
552 </qandaentry>
553
554 <qandaentry>
555 <question>
556 <para id='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>
557 How does the OpenEmbedded build system obtain source code and
558 will it work behind my firewall or proxy server?
559 </para>
560 </question>
561 <answer>
562 <para>
563 The way the build system obtains source code is highly
564 configurable.
565 You can setup the build system to get source code in most
566 environments if HTTP transport is available.
567 </para>
568 <para>
569 When the build system searches for source code, it first
570 tries the local download directory.
571 If that location fails, Poky tries
572 <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>,
573 the upstream source, and then
574 <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
575 in that order.
576 </para>
577 <para>
578 Assuming your distribution is "poky", the OpenEmbedded build
579 system uses the Yocto Project source
580 <filename>PREMIRRORS</filename> by default for SCM-based
581 sources, upstreams for normal tarballs, and then falls back
582 to a number of other mirrors including the Yocto Project
583 source mirror if those fail.
584 </para>
585 <para>
586 As an example, you could add a specific server for the
587 build system to attempt before any others by adding something
588 like the following to the <filename>local.conf</filename>
589 configuration file:
590 <literallayout class='monospaced'>
591 PREMIRRORS_prepend = "\
592 git://.*/.* http://www.yoctoproject.org/sources/ \n \
593 ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
594 http://.*/.* http://www.yoctoproject.org/sources/ \n \
595 https://.*/.* http://www.yoctoproject.org/sources/ \n"
596 </literallayout>
597 </para>
598 <para>
599 These changes cause the build system to intercept Git, FTP,
600 HTTP, and HTTPS requests and direct them to the
601 <filename>http://</filename> sources mirror.
602 You can use <filename>file://</filename> URLs to point to
603 local directories or network shares as well.
604 </para>
605 <para>
606 Aside from the previous technique, these options also exist:
607 <literallayout class='monospaced'>
608 BB_NO_NETWORK = "1"
609 </literallayout>
610 This statement tells BitBake to issue an error instead of
611 trying to access the Internet.
612 This technique is useful if you want to ensure code builds
613 only from local sources.
614 </para>
615 <para>
616 Here is another technique:
617 <literallayout class='monospaced'>
618 BB_FETCH_PREMIRRORONLY = "1"
619 </literallayout>
620 This statement limits the build system to pulling source
621 from the <filename>PREMIRRORS</filename> only.
622 Again, this technique is useful for reproducing builds.
623 </para>
624 <para>
625 Here is another technique:
626 <literallayout class='monospaced'>
627 BB_GENERATE_MIRROR_TARBALLS = "1"
628 </literallayout>
629 This statement tells the build system to generate mirror
630 tarballs.
631 This technique is useful if you want to create a mirror server.
632 If not, however, the technique can simply waste time during
633 the build.
634 </para>
635 <para>
636 Finally, consider an example where you are behind an
637 HTTP-only firewall.
638 You could make the following changes to the
639 <filename>local.conf</filename> configuration file as long as
640 the <filename>PREMIRRORS</filename> server is current:
641 <literallayout class='monospaced'>
642 PREMIRRORS_prepend = "\
643 ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
644 http://.*/.* http://www.yoctoproject.org/sources/ \n \
645 https://.*/.* http://www.yoctoproject.org/sources/ \n"
646 BB_FETCH_PREMIRRORONLY = "1"
647 </literallayout>
648 These changes would cause the build system to successfully
649 fetch source over HTTP and any network accesses to anything
650 other than the <filename>PREMIRRORS</filename> would fail.
651 </para>
652 <para>
653 The build system also honors the standard shell environment
654 variables <filename>http_proxy</filename>,
655 <filename>ftp_proxy</filename>,
656 <filename>https_proxy</filename>, and
657 <filename>all_proxy</filename> to redirect requests through
658 proxy servers.
659 </para>
660 </answer>
661 </qandaentry>
662
663 <qandaentry>
664 <question>
665 <para>
666 Can I get rid of build output so I can start over?
667 </para>
668 </question>
669 <answer>
670 <para>
671 Yes - you can easily do this.
672 When you use BitBake to build an image, all the build output
673 goes into the directory created when you run the
674 build environment setup script (i.e.
675 <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
676 or
677 <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
678 By default, this <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
679 is named <filename>build</filename> but can be named
680 anything you want.
681 </para>
682
683 <para>
684 Within the Build Directory, is the <filename>tmp</filename>
685 directory.
686 To remove all the build output yet preserve any source code or
687 downloaded files from previous builds, simply remove the
688 <filename>tmp</filename> directory.
689 </para>
690 </answer>
691 </qandaentry>
692
693
694</qandaset>
695</chapter>
696<!--
697vim: expandtab tw=80 ts=4
698-->
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-05-29 06:23:33 +0000