Download meta.bbclass - Yocto Project

FAQ
This statement tells the build system to generate mirror tarballs. This technique is useful if you
want to create a mirror server. If not, however, the technique can simply waste time during
the build.
Finally, consider an example where you are behind an HTTP-only firewall. You could make the
following changes to the local.conf configuration file as long as the PREMIRRORS server is
current:
PREMIRRORS_prepend = "\
ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
http://.*/.* http://www.yoctoproject.org/sources/ \n \
https://.*/.* http://www.yoctoproject.org/sources/ \n"
BB_FETCH_PREMIRRORONLY = "1"
These changes would cause the build system to successfully fetch source over HTTP and any
network accesses to anything other than the PREMIRRORS would fail.
The build system also honors the standard shell environment variables http_proxy, ftp_proxy,
https_proxy, and all_proxy to redirect requests through proxy servers.
Note
You can find more information on the "Working Behind a Network Proxy [https://
wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy]" Wiki page.
14.23.Can I get rid of build output so I can start over?
Yes - you can easily do this. When you use BitBake to build an image, all the build output
goes into the directory created when you run the build environment setup script (i.e. oeinit-build-env or oe-init-build-env-memres). By default, this Build Directory [http://
www.yoctoproject.org/docs/1.7/dev-manual/dev-manual.html#build-directory] is named build
but can be named anything you want.
Within the Build Directory, is the tmp directory. To remove all the build output yet preserve any
source code or downloaded files from previous builds, simply remove the tmp directory.
14.24.Why do ${bindir} and ${libdir} have strange values for -native recipes?
Executables and libraries might need to be used from a directory other than the directory
into which they were initially installed. Complicating this situation is the fact that sometimes
these executables and libraries are compiled with the expectation of being run from that initial
installation target directory. If this is the case, moving them causes problems.
This scenario is a fundamental problem for package maintainers of mainstream Linux
distributions as well as for the OpenEmbedded build system. As such, a well-established
solution exists. Makefiles, Autotools configuration scripts, and other build systems are expected
to respect environment variables such as bindir, libdir, and sysconfdir that indicate where
executables, libraries, and data reside when a program is actually run. They are also expected
to respect a DESTDIR environment variable, which is prepended to all the other variables when
the build system actually installs the files. It is understood that the program does not actually
run from within DESTDIR.
When the OpenEmbedded build system uses a recipe to build a target-architecture program
(i.e. one that is intended for inclusion on the image being built), that program eventually runs
from the root file system of that image. Thus, the build system provides a value of "/usr/bin"
for bindir, a value of "/usr/lib" for libdir, and so forth.
Meanwhile, DESTDIR is a path within the Build Directory [http://www.yoctoproject.org/docs/1.7/
dev-manual/dev-manual.html#build-directory]. However, when the recipe builds a native
program (i.e. one that is intended to run on the build machine), that program is never installed
directly to the build machine's root file system. Consequently, the build system uses paths
within the Build Directory for DESTDIR, bindir and related variables. To better understand this,
consider the following two paths where the first is relatively normal and the second is not:
214