diff options
Diffstat (limited to 'meta-boot2qt-distro/conf/local.conf.sample')
-rw-r--r-- | meta-boot2qt-distro/conf/local.conf.sample | 289 |
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 | ||
50 | BB_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 | ||
56 | PARALLEL_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: | ||
83 | MACHINE ??= "qemux86" | ||
84 | MACHINE_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 | # | ||
97 | DL_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 | # | ||
113 | SSTATE_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 | # | ||
135 | DISTRO ?= "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: | ||
154 | PACKAGE_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. | ||
187 | EXTRA_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 | ||
201 | USER_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): | ||
228 | PATCHRESOLVE = "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. | ||
238 | BB_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. | ||
278 | CONF_VERSION = "1" | ||
279 | |||
280 | #INHERIT += "rm_work" | ||
281 | INHERIT += "image-buildinfo" | ||
282 | INHERIT += "internal-build" | ||
283 | |||
284 | ACCEPT_FSL_EULA = "1" | ||
285 | LICENSE_FLAGS_WHITELIST = "commercial" | ||
286 | |||
287 | QT_SDK_PATH = "" | ||
288 | |||
289 | include conf/distro/include/${MACHINE}.pre.inc | ||