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