| # |
| # 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 |
| # |
| MACHINE ??= "greatlakes" |
| |
| # |
| # 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 ?= "openbmc-phosphor" |
| # 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 ipk: |
| PACKAGE_CLASSES ?= "package_ipk" |
| |
| # |
| # 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, x86_64, aarch64 |
| #SDKMACHINE ?= "i686" |
| |
| SANITY_TESTED_DISTROS:append ?= " *" |
| |
| # |
| # 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) |
| # "src-pkgs" - add -src packages for all installed packages |
| # (adds source code for debugging) |
| # "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 |
| USER_CLASSES ?= "buildstats" |
| |
| # |
| # 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. It can also |
| # run tests against any SDK that are built. To enable this uncomment these lines. |
| # See classes/test{image,sdk}.bbclass for further details. |
| #IMAGE_CLASSES += "testimage testsdk" |
| #TESTIMAGE_AUTO_qemuall = "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 than 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 necessary 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 \ |
| HALT,${TMPDIR},100M,1K \ |
| HALT,${DL_DIR},100M,1K \ |
| HALT,${SSTATE_DIR},100M,1K \ |
| HALT,/tmp,10M,1K" |
| |
| # |
| # Shared-state files from other locations |
| # |
| # As mentioned above, shared state files are prebuilt cache data objects which can be |
| # 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" |
| |
| # |
| # Yocto Project SState Mirror |
| # |
| # The Yocto Project has prebuilt artefacts available for its releases, you can enable |
| # use of these by uncommenting the following line. This will mean the build uses |
| # the network to check for artefacts at the start of builds, which does slow it down |
| # equally, it will also speed up the builds by not having to build things if they are |
| # present in the cache. It assumes you can download something faster than you can build it |
| # which will depend on your network. |
| # |
| #SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH" |
| |
| # |
| # Qemu configuration |
| # |
| # By default native qemu will build with a builtin VNC server where graphical output can be |
| # seen. The line below enables the SDL UI frontend too. |
| PACKAGECONFIG:append:pn-qemu-system-native = " sdl" |
| # By default libsdl2-native will be built, if you want to use your host's libSDL instead of |
| # the minimal libsdl built by libsdl2-native then uncomment the ASSUME_PROVIDED line below. |
| #ASSUME_PROVIDED += "libsdl2-native" |
| |
| # You can also enable the Gtk UI frontend, which takes somewhat longer to build, but adds |
| # a handy set of menus for controlling the emulator. |
| #PACKAGECONFIG:append:pn-qemu-system-native = " gtk+" |
| |
| # |
| # Hash Equivalence |
| # |
| # Enable support for automatically running a local hash equivalence server and |
| # instruct bitbake to use a hash equivalence aware signature generator. Hash |
| # equivalence improves reuse of sstate by detecting when a given sstate |
| # artifact can be reused as equivalent, even if the current task hash doesn't |
| # match the one that generated the artifact. |
| # |
| # A shared hash equivalent server can be set with "<HOSTNAME>:<PORT>" format |
| # |
| #BB_HASHSERVE = "auto" |
| #BB_SIGNATURE_HANDLER = "OEEquivHash" |
| |
| # |
| # Memory Resident Bitbake |
| # |
| # Bitbake's server component can stay in memory after the UI for the current command |
| # has completed. This means subsequent commands can run faster since there is no need |
| # for bitbake to reload cache files and so on. Number is in seconds, after which the |
| # server will shut down. |
| # |
| #BB_SERVER_TIMEOUT = "60" |
| |
| # 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 = "2" |
| |
| # Set the root password to '0penBmc' |
| # Defaults from meta-phosphor/conf/distro/include/phosphor-defaults.inc |