| # |
| # This file is your local configuration file and is where all local user settings |
| # are placed. The comments in this file give some guide to the options a new user |
| # to the system might want to change but pretty much any configuration option can |
| # be set in this file. More adventurous users can look at local.conf.extended |
| # which contains other examples of configuration which can be placed in this file |
| # but new users likely won't need any of them initially. |
| # |
| # Lines starting with the '#' character are commented out and in some cases the |
| # default values are provided as comments to show people example syntax. Enabling |
| # the option is a question of removing the # character and making any change to the |
| # variable as required. |
| |
| # |
| # Machine Selection |
| # |
| # You need to select a specific machine to target the build with. There are a selection |
| # of emulated machines available which can boot and run in the QEMU emulator: |
| # |
| #MACHINE ?= "qemuarm" |
| #MACHINE ?= "qemuarm64" |
| #MACHINE ?= "qemumips" |
| #MACHINE ?= "qemumips64" |
| #MACHINE ?= "qemuppc" |
| #MACHINE ?= "qemux86" |
| #MACHINE ?= "qemux86-64" |
| # |
| # There are also the following hardware board target machines included for |
| # demonstration purposes: |
| # |
| #MACHINE ?= "beaglebone" |
| #MACHINE ?= "genericx86" |
| #MACHINE ?= "genericx86-64" |
| #MACHINE ?= "mpc8315e-rdb" |
| #MACHINE ?= "edgerouter" |
| # |
| # This sets the default machine to be qemux86 if no other machine is selected: |
| MACHINE ??= "qemux86" |
| |
| # |
| # Where to place downloads |
| # |
| # During a first build the system will download many different source code tarballs |
| # from various upstream projects. This can take a while, particularly if your network |
| # connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you |
| # can preserve this directory to speed up this part of subsequent builds. This directory |
| # is safe to share between multiple builds on the same machine too. |
| # |
| # The default is a downloads directory under TOPDIR which is the build directory. |
| # |
| #DL_DIR ?= "${TOPDIR}/downloads" |
| |
| # |
| # Where to place shared-state files |
| # |
| # BitBake has the capability to accelerate builds based on previously built output. |
| # This is done using "shared state" files which can be thought of as cache objects |
| # and this option determines where those files are placed. |
| # |
| # You can wipe out TMPDIR leaving this directory intact and the build would regenerate |
| # from these files if no changes were made to the configuration. If changes were made |
| # to the configuration, only shared state files where the state was still valid would |
| # be used (done using checksums). |
| # |
| # The default is a sstate-cache directory under TOPDIR. |
| # |
| #SSTATE_DIR ?= "${TOPDIR}/sstate-cache" |
| |
| # |
| # Where to place the build output |
| # |
| # This option specifies where the bulk of the building work should be done and |
| # where BitBake should place its temporary files and output. Keep in mind that |
| # this includes the extraction and compilation of many applications and the toolchain |
| # which can use Gigabytes of hard disk space. |
| # |
| # The default is a tmp directory under TOPDIR. |
| # |
| #TMPDIR = "${TOPDIR}/tmp" |
| |
| # |
| # Default policy config |
| # |
| # The distribution setting controls which policy settings are used as defaults. |
| # The default value is fine for general Yocto project use, at least initially. |
| # Ultimately when creating custom policy, people will likely end up subclassing |
| # these defaults. |
| # |
| DISTRO ?= "poky" |
| # As an example of a subclass there is a "bleeding" edge policy configuration |
| # where many versions are set to the absolute latest code from the upstream |
| # source control systems. This is just mentioned here as an example, its not |
| # useful to most new users. |
| # DISTRO ?= "poky-bleeding" |
| |
| # |
| # Package Management configuration |
| # |
| # This variable lists which packaging formats to enable. Multiple package backends |
| # can be enabled at once and the first item listed in the variable will be used |
| # to generate the root filesystems. |
| # Options are: |
| # - 'package_deb' for debian style deb files |
| # - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager) |
| # - 'package_rpm' for rpm style packages |
| # E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk" |
| # We default to rpm: |
| PACKAGE_CLASSES ?= "package_rpm" |
| |
| # |
| # SDK target architecture |
| # |
| # This variable specifies the architecture to build SDK items for and means |
| # you can build the SDK packages for architectures other than the machine you are |
| # running the build on (i.e. building i686 packages on an x86_64 host). |
| # Supported values are i686 and x86_64 |
| #SDKMACHINE ?= "i686" |
| |
| # |
| # Extra image configuration defaults |
| # |
| # The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated |
| # images. Some of these options are added to certain image types automatically. The |
| # variable can contain the following options: |
| # "dbg-pkgs" - add -dbg packages for all installed packages |
| # (adds symbol information for debugging/profiling) |
| # "dev-pkgs" - add -dev packages for all installed packages |
| # (useful if you want to develop against libs in the image) |
| # "ptest-pkgs" - add -ptest packages for all ptest-enabled packages |
| # (useful if you want to run the package test suites) |
| # "tools-sdk" - add development tools (gcc, make, pkgconfig etc.) |
| # "tools-debug" - add debugging tools (gdb, strace) |
| # "eclipse-debug" - add Eclipse remote debugging support |
| # "tools-profile" - add profiling tools (oprofile, lttng, valgrind) |
| # "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.) |
| # "debug-tweaks" - make an image suitable for development |
| # e.g. ssh root access has a blank password |
| # There are other application targets that can be used here too, see |
| # meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details. |
| # We default to enabling the debugging tweaks. |
| EXTRA_IMAGE_FEATURES ?= "debug-tweaks" |
| |
| # |
| # Additional image features |
| # |
| # The following is a list of additional classes to use when building images which |
| # enable extra features. Some available options which can be included in this variable |
| # are: |
| # - 'buildstats' collect build statistics |
| # - 'image-mklibs' to reduce shared library files size for an image |
| # - 'image-prelink' in order to prelink the filesystem image |
| # - 'image-swab' to perform host system intrusion detection |
| # NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink |
| # NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended |
| USER_CLASSES ?= "buildstats image-mklibs image-prelink" |
| |
| # |
| # Runtime testing of images |
| # |
| # The build system can test booting virtual machine images under qemu (an emulator) |
| # after any root filesystems are created and run tests against those images. To |
| # enable this uncomment this line. See classes/testimage(-auto).bbclass for |
| # further details. |
| #TEST_IMAGE = "1" |
| # |
| # Interactive shell configuration |
| # |
| # Under certain circumstances the system may need input from you and to do this it |
| # can launch an interactive shell. It needs to do this since the build is |
| # multithreaded and needs to be able to handle the case where more than one parallel |
| # process may require the user's attention. The default is iterate over the available |
| # terminal types to find one that works. |
| # |
| # Examples of the occasions this may happen are when resolving patches which cannot |
| # be applied, to use the devshell or the kernel menuconfig |
| # |
| # Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none |
| # Note: currently, Konsole support only works for KDE 3.x due to the way |
| # newer Konsole versions behave |
| #OE_TERMINAL = "auto" |
| # By default disable interactive patch resolution (tasks will just fail instead): |
| PATCHRESOLVE = "noop" |
| |
| # |
| # Disk Space Monitoring during the build |
| # |
| # Monitor the disk space during the build. If there is less that 1GB of space or less |
| # than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully |
| # shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort |
| # of the build. The reason for this is that running completely out of space can corrupt |
| # files and damages the build in ways which may not be easily recoverable. |
| # It's necesary to monitor /tmp, if there is no space left the build will fail |
| # with very exotic errors. |
| BB_DISKMON_DIRS = "\ |
| STOPTASKS,${TMPDIR},1G,100K \ |
| STOPTASKS,${DL_DIR},1G,100K \ |
| STOPTASKS,${SSTATE_DIR},1G,100K \ |
| STOPTASKS,/tmp,100M,100K \ |
| ABORT,${TMPDIR},100M,1K \ |
| ABORT,${DL_DIR},100M,1K \ |
| ABORT,${SSTATE_DIR},100M,1K \ |
| ABORT,/tmp,10M,1K" |
| |
| # |
| # Shared-state files from other locations |
| # |
| # As mentioned above, shared state files are prebuilt cache data objects which can |
| # used to accelerate build time. This variable can be used to configure the system |
| # to search other mirror locations for these objects before it builds the data itself. |
| # |
| # This can be a filesystem directory, or a remote url such as http or ftp. These |
| # would contain the sstate-cache results from previous builds (possibly from other |
| # machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the |
| # cache locations to check for the shared objects. |
| # NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH |
| # at the end as shown in the examples below. This will be substituted with the |
| # correct path within the directory structure. |
| #SSTATE_MIRRORS ?= "\ |
| #file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \ |
| #file://.* file:///some/local/dir/sstate/PATH" |
| |
| |
| # |
| # Qemu configuration |
| # |
| # By default qemu will build with a builtin VNC server where graphical output can be |
| # seen. The two lines below enable the SDL backend too. By default libsdl-native will |
| # be built, if you want to use your host's libSDL instead of the minimal libsdl built |
| # by libsdl-native then uncomment the ASSUME_PROVIDED line below. |
| PACKAGECONFIG_append_pn-qemu-native = " sdl" |
| PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl" |
| #ASSUME_PROVIDED += "libsdl-native" |
| |
| # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to |
| # track the version of this file when it was generated. This can safely be ignored if |
| # this doesn't mean anything to you. |
| CONF_VERSION = "1" |