1# 2# This file is your local configuration file and is where all local user settings 3# are placed. The comments in this file give some guide to the options a new user 4# to the system might want to change but pretty much any configuration option can 5# be set in this file. 6# 7# Lines starting with the '#' character are commented out and in some cases the 8# default values are provided as comments to show people example syntax. Enabling 9# the option is a question of removing the # character and making any change to the 10# variable as required. 11 12# 13# Machine Selection 14# 15MACHINE ??= "mtmitchell" 16 17# 18# Where to place downloads 19# 20# During a first build the system will download many different source code tarballs 21# from various upstream projects. This can take a while, particularly if your network 22# connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you 23# can preserve this directory to speed up this part of subsequent builds. This directory 24# is safe to share between multiple builds on the same machine too. 25# 26# The default is a downloads directory under TOPDIR which is the build directory. 27# 28#DL_DIR ?= "${TOPDIR}/downloads" 29 30# 31# Where to place shared-state files 32# 33# BitBake has the capability to accelerate builds based on previously built output. 34# This is done using "shared state" files which can be thought of as cache objects 35# and this option determines where those files are placed. 36# 37# You can wipe out TMPDIR leaving this directory intact and the build would regenerate 38# from these files if no changes were made to the configuration. If changes were made 39# to the configuration, only shared state files where the state was still valid would 40# be used (done using checksums). 41# 42# The default is a sstate-cache directory under TOPDIR. 43# 44#SSTATE_DIR ?= "${TOPDIR}/sstate-cache" 45 46# 47# Where to place the build output 48# 49# This option specifies where the bulk of the building work should be done and 50# where BitBake should place its temporary files and output. Keep in mind that 51# this includes the extraction and compilation of many applications and the toolchain 52# which can use Gigabytes of hard disk space. 53# 54# The default is a tmp directory under TOPDIR. 55# 56#TMPDIR = "${TOPDIR}/tmp" 57 58# 59# Default policy config 60# 61# The distribution setting controls which policy settings are used as defaults. 62# The default value is fine for general Yocto project use, at least initially. 63# Ultimately when creating custom policy, people will likely end up subclassing 64# these defaults. 65# 66DISTRO ?= "openbmc-phosphor" 67# As an example of a subclass there is a "bleeding" edge policy configuration 68# where many versions are set to the absolute latest code from the upstream 69# source control systems. This is just mentioned here as an example, its not 70# useful to most new users. 71# DISTRO ?= "poky-bleeding" 72 73# 74# Package Management configuration 75# 76# This variable lists which packaging formats to enable. Multiple package backends 77# can be enabled at once and the first item listed in the variable will be used 78# to generate the root filesystems. 79# Options are: 80# - 'package_deb' for debian style deb files 81# - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager) 82# - 'package_rpm' for rpm style packages 83# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk" 84# We default to ipk: 85PACKAGE_CLASSES ?= "package_ipk" 86 87# 88# SDK/ADT target architecture 89# 90# This variable specifies the architecture to build SDK/ADT items for and means 91# you can build the SDK packages for architectures other than the machine you are 92# running the build on (i.e. building i686 packages on an x86_64 host). 93# Supported values are i686 and x86_64 94#SDKMACHINE ?= "i686" 95 96SANITY_TESTED_DISTROS:append ?= " *" 97 98# 99# Extra image configuration defaults 100# 101# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated 102# images. Some of these options are added to certain image types automatically. The 103# variable can contain the following options: 104# "dbg-pkgs" - add -dbg packages for all installed packages 105# (adds symbol information for debugging/profiling) 106# "dev-pkgs" - add -dev packages for all installed packages 107# (useful if you want to develop against libs in the image) 108# "ptest-pkgs" - add -ptest packages for all ptest-enabled packages 109# (useful if you want to run the package test suites) 110# "tools-sdk" - add development tools (gcc, make, pkgconfig etc.) 111# "tools-debug" - add debugging tools (gdb, strace) 112# "eclipse-debug" - add Eclipse remote debugging support 113# "tools-profile" - add profiling tools (oprofile, exmap, lttng, valgrind) 114# "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.) 115# "debug-tweaks" - make an image suitable for development 116# e.g. ssh root access has a blank password 117# There are other application targets that can be used here too, see 118# meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details. 119# We default to enabling the debugging tweaks. 120EXTRA_IMAGE_FEATURES ?= "debug-tweaks" 121 122# 123# Additional image features 124# 125# The following is a list of additional classes to use when building images which 126# enable extra features. Some available options which can be included in this variable 127# are: 128# - 'buildstats' collect build statistics 129# - 'image-swab' to perform host system intrusion detection 130# NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink 131# NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended 132USER_CLASSES ?= "buildstats" 133 134# 135# Runtime testing of images 136# 137# The build system can test booting virtual machine images under qemu (an emulator) 138# after any root filesystems are created and run tests against those images. To 139# enable this uncomment this line. See classes/testimage(-auto).bbclass for 140# further details. 141#TEST_IMAGE = "1" 142# 143# Interactive shell configuration 144# 145# Under certain circumstances the system may need input from you and to do this it 146# can launch an interactive shell. It needs to do this since the build is 147# multithreaded and needs to be able to handle the case where more than one parallel 148# process may require the user's attention. The default is iterate over the available 149# terminal types to find one that works. 150# 151# Examples of the occasions this may happen are when resolving patches which cannot 152# be applied, to use the devshell or the kernel menuconfig 153# 154# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none 155# Note: currently, Konsole support only works for KDE 3.x due to the way 156# newer Konsole versions behave 157#OE_TERMINAL = "auto" 158# By default disable interactive patch resolution (tasks will just fail instead): 159PATCHRESOLVE = "noop" 160 161# 162# Disk Space Monitoring during the build 163# 164# Monitor the disk space during the build. If there is less that 1GB of space or less 165# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully 166# shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort 167# of the build. The reason for this is that running completely out of space can corrupt 168# files and damages the build in ways which may not be easily recoverable. 169# It's necessary to monitor /tmp, if there is no space left the build will fail 170# with very exotic errors. 171BB_DISKMON_DIRS ??= "\ 172 STOPTASKS,${TMPDIR},1G,100K \ 173 STOPTASKS,${DL_DIR},1G,100K \ 174 STOPTASKS,${SSTATE_DIR},1G,100K \ 175 STOPTASKS,/tmp,100M,100K \ 176 HALT,${TMPDIR},100M,1K \ 177 HALT,${DL_DIR},100M,1K \ 178 HALT,${SSTATE_DIR},100M,1K \ 179 HALT,/tmp,10M,1K" 180 181# 182# Shared-state files from other locations 183# 184# As mentioned above, shared state files are prebuilt cache data objects which can 185# used to accelerate build time. This variable can be used to configure the system 186# to search other mirror locations for these objects before it builds the data itself. 187# 188# This can be a filesystem directory, or a remote url such as http or ftp. These 189# would contain the sstate-cache results from previous builds (possibly from other 190# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the 191# cache locations to check for the shared objects. 192# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH 193# at the end as shown in the examples below. This will be substituted with the 194# correct path within the directory structure. 195#SSTATE_MIRRORS ?= "\ 196#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \ 197#file://.* file:///some/local/dir/sstate/PATH" 198 199 200# 201# Qemu configuration 202# 203# By default qemu will build with a builtin VNC server where graphical output can be 204# seen. The two lines below enable the SDL backend too. This assumes there is a 205# libsdl library available on your build system. 206#PACKAGECONFIG_append_pn-qemu-native = " sdl" 207#PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl" 208#ASSUME_PROVIDED += "libsdl-native" 209 210 211# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to 212# track the version of this file when it was generated. This can safely be ignored if 213# this doesn't mean anything to you. 214CONF_VERSION = "2" 215