summaryrefslogtreecommitdiffstats
path: root/meta-boot2qt-distro/conf/local.conf.sample
diff options
context:
space:
mode:
Diffstat (limited to 'meta-boot2qt-distro/conf/local.conf.sample')
-rw-r--r--meta-boot2qt-distro/conf/local.conf.sample289
1 files changed, 289 insertions, 0 deletions
diff --git a/meta-boot2qt-distro/conf/local.conf.sample b/meta-boot2qt-distro/conf/local.conf.sample
new file mode 100644
index 0000000..ae60ef4
--- /dev/null
+++ b/meta-boot2qt-distro/conf/local.conf.sample
@@ -0,0 +1,289 @@
1############################################################################
2##
3## Copyright (C) 2016 The Qt Company Ltd.
4## Contact: https://www.qt.io/licensing/
5##
6## This file is part of the Boot to Qt meta layer.
7##
8## $QT_BEGIN_LICENSE:GPL$
9## Commercial License Usage
10## Licensees holding valid commercial Qt licenses may use this file in
11## accordance with the commercial license agreement provided with the
12## Software or, alternatively, in accordance with the terms contained in
13## a written agreement between you and The Qt Company. For licensing terms
14## and conditions see https://www.qt.io/terms-conditions. For further
15## information use the contact form at https://www.qt.io/contact-us.
16##
17## GNU General Public License Usage
18## Alternatively, this file may be used under the terms of the GNU
19## General Public License version 3 or (at your option) any later version
20## approved by the KDE Free Qt Foundation. The licenses are as published by
21## the Free Software Foundation and appearing in the file LICENSE.GPL3
22## included in the packaging of this file. Please review the following
23## information to ensure the GNU General Public License requirements will
24## be met: https://www.gnu.org/licenses/gpl-3.0.html.
25##
26## $QT_END_LICENSE$
27##
28############################################################################
29
30#
31# This file is your local configuration file and is where all local user settings
32# are placed. The comments in this file give some guide to the options a new user
33# to the system might want to change but pretty much any configuration option can
34# be set in this file. More adventurous users can look at local.conf.extended
35# which contains other examples of configuration which can be placed in this file
36# but new users likely won't need any of them initially.
37#
38# Lines starting with the '#' character are commented out and in some cases the
39# default values are provided as comments to show people example syntax. Enabling
40# the option is a question of removing the # character and making any change to the
41# variable as required.
42
43#
44# Parallelism Options
45#
46# These two options control how much parallelism BitBake should use. The first
47# option determines how many tasks bitbake should run in parallel:
48#
49# Default to setting automatically based on cpu count
50BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"
51#
52# The second option controls how many processes make should run in parallel when
53# running compile tasks:
54#
55# Default to setting automatically based on cpu count
56PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
57#
58# For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would
59# be appropriate for example.
60
61#
62# Machine Selection
63#
64# You need to select a specific machine to target the build with. There are a selection
65# of emulated machines available which can boot and run in the QEMU emulator:
66#
67#MACHINE ?= "qemuarm"
68#MACHINE ?= "qemumips"
69#MACHINE ?= "qemuppc"
70#MACHINE ?= "qemux86"
71#MACHINE ?= "qemux86-64"
72#
73# There are also the following hardware board target machines included for
74# demonstration purposes:
75#
76#MACHINE ?= "beaglebone"
77#MACHINE ?= "genericx86"
78#MACHINE ?= "genericx86-64"
79#MACHINE ?= "mpc8315e-rdb"
80#MACHINE ?= "edgerouter"
81#
82# This sets the default machine to be qemux86 if no other machine is selected:
83MACHINE ??= "qemux86"
84MACHINE_HOSTNAME ?= "b2qt-${MACHINE}"
85
86#
87# Where to place downloads
88#
89# During a first build the system will download many different source code tarballs
90# from various upstream projects. This can take a while, particularly if your network
91# connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
92# can preserve this directory to speed up this part of subsequent builds. This directory
93# is safe to share between multiple builds on the same machine too.
94#
95# The default is a downloads directory under TOPDIR which is the build directory.
96#
97DL_DIR ?= "${TOPDIR}/../downloads"
98
99#
100# Where to place shared-state files
101#
102# BitBake has the capability to accelerate builds based on previously built output.
103# This is done using "shared state" files which can be thought of as cache objects
104# and this option determines where those files are placed.
105#
106# You can wipe out TMPDIR leaving this directory intact and the build would regenerate
107# from these files if no changes were made to the configuration. If changes were made
108# to the configuration, only shared state files where the state was still valid would
109# be used (done using checksums).
110#
111# The default is a sstate-cache directory under TOPDIR.
112#
113SSTATE_DIR ?= "${TOPDIR}/../sstate-cache"
114
115#
116# Where to place the build output
117#
118# This option specifies where the bulk of the building work should be done and
119# where BitBake should place its temporary files and output. Keep in mind that
120# this includes the extraction and compilation of many applications and the toolchain
121# which can use Gigabytes of hard disk space.
122#
123# The default is a tmp directory under TOPDIR.
124#
125#TMPDIR = "${TOPDIR}/tmp"
126
127#
128# Default policy config
129#
130# The distribution setting controls which policy settings are used as defaults.
131# The default value is fine for general Yocto project use, at least initially.
132# Ultimately when creating custom policy, people will likely end up subclassing
133# these defaults.
134#
135DISTRO ?= "b2qt"
136# As an example of a subclass there is a "bleeding" edge policy configuration
137# where many versions are set to the absolute latest code from the upstream
138# source control systems. This is just mentioned here as an example, its not
139# useful to most new users.
140# DISTRO ?= "poky-bleeding"
141
142#
143# Package Management configuration
144#
145# This variable lists which packaging formats to enable. Multiple package backends
146# can be enabled at once and the first item listed in the variable will be used
147# to generate the root filesystems.
148# Options are:
149# - 'package_deb' for debian style deb files
150# - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
151# - 'package_rpm' for rpm style packages
152# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
153# We default to rpm:
154PACKAGE_CLASSES ?= "package_ipk"
155
156#
157# SDK/ADT target architecture
158#
159# This variable specifies the architecture to build SDK/ADT items for and means
160# you can build the SDK packages for architectures other than the machine you are
161# running the build on (i.e. building i686 packages on an x86_64 host).
162# Supported values are i686 and x86_64
163#SDKMACHINE ?= "i686"
164
165#
166# Extra image configuration defaults
167#
168# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
169# images. Some of these options are added to certain image types automatically. The
170# variable can contain the following options:
171# "dbg-pkgs" - add -dbg packages for all installed packages
172# (adds symbol information for debugging/profiling)
173# "dev-pkgs" - add -dev packages for all installed packages
174# (useful if you want to develop against libs in the image)
175# "ptest-pkgs" - add -ptest packages for all ptest-enabled packages
176# (useful if you want to run the package test suites)
177# "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
178# "tools-debug" - add debugging tools (gdb, strace)
179# "eclipse-debug" - add Eclipse remote debugging support
180# "tools-profile" - add profiling tools (oprofile, exmap, lttng, valgrind)
181# "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
182# "debug-tweaks" - make an image suitable for development
183# e.g. ssh root access has a blank password
184# There are other application targets that can be used here too, see
185# meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
186# We default to enabling the debugging tweaks.
187EXTRA_IMAGE_FEATURES = "debug-tweaks"
188
189#
190# Additional image features
191#
192# The following is a list of additional classes to use when building images which
193# enable extra features. Some available options which can be included in this variable
194# are:
195# - 'buildstats' collect build statistics
196# - 'image-mklibs' to reduce shared library files size for an image
197# - 'image-prelink' in order to prelink the filesystem image
198# - 'image-swab' to perform host system intrusion detection
199# NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
200# NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
201USER_CLASSES ?= "buildstats image-mklibs"
202
203#
204# Runtime testing of images
205#
206# The build system can test booting virtual machine images under qemu (an emulator)
207# after any root filesystems are created and run tests against those images. To
208# enable this uncomment this line. See classes/testimage(-auto).bbclass for
209# further details.
210#TEST_IMAGE = "1"
211#
212# Interactive shell configuration
213#
214# Under certain circumstances the system may need input from you and to do this it
215# can launch an interactive shell. It needs to do this since the build is
216# multithreaded and needs to be able to handle the case where more than one parallel
217# process may require the user's attention. The default is iterate over the available
218# terminal types to find one that works.
219#
220# Examples of the occasions this may happen are when resolving patches which cannot
221# be applied, to use the devshell or the kernel menuconfig
222#
223# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
224# Note: currently, Konsole support only works for KDE 3.x due to the way
225# newer Konsole versions behave
226#OE_TERMINAL = "auto"
227# By default disable interactive patch resolution (tasks will just fail instead):
228PATCHRESOLVE = "noop"
229
230#
231# Disk Space Monitoring during the build
232#
233# Monitor the disk space during the build. If there is less that 1GB of space or less
234# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
235# shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort
236# of the build. The reason for this is that running completely out of space can corrupt
237# files and damages the build in ways which may not be easily recoverable.
238BB_DISKMON_DIRS = "\
239 STOPTASKS,${TMPDIR},1G,100K \
240 STOPTASKS,${DL_DIR},1G,100K \
241 STOPTASKS,${SSTATE_DIR},1G,100K \
242 ABORT,${TMPDIR},100M,1K \
243 ABORT,${DL_DIR},100M,1K \
244 ABORT,${SSTATE_DIR},100M,1K"
245
246#
247# Shared-state files from other locations
248#
249# As mentioned above, shared state files are prebuilt cache data objects which can
250# used to accelerate build time. This variable can be used to configure the system
251# to search other mirror locations for these objects before it builds the data itself.
252#
253# This can be a filesystem directory, or a remote url such as http or ftp. These
254# would contain the sstate-cache results from previous builds (possibly from other
255# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
256# cache locations to check for the shared objects.
257# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
258# at the end as shown in the examples below. This will be substituted with the
259# correct path within the directory structure.
260#SSTATE_MIRRORS ?= "\
261#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
262#file://.* file:///some/local/dir/sstate/PATH"
263
264#
265# Qemu configuration
266#
267# By default qemu will build with a builtin VNC server where graphical output can be
268# seen. The two lines below enable the SDL backend too. This assumes there is a
269# libsdl library available on your build system.
270#PACKAGECONFIG_pn-qemu-native = "sdl"
271#PACKAGECONFIG_pn-nativesdk-qemu = "sdl"
272#ASSUME_PROVIDED += "libsdl-native"
273
274
275# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
276# track the version of this file when it was generated. This can safely be ignored if
277# this doesn't mean anything to you.
278CONF_VERSION = "1"
279
280#INHERIT += "rm_work"
281INHERIT += "image-buildinfo"
282INHERIT += "internal-build"
283
284ACCEPT_FSL_EULA = "1"
285LICENSE_FLAGS_WHITELIST = "commercial"
286
287QT_SDK_PATH = ""
288
289include conf/distro/include/${MACHINE}.pre.inc