Handle image-prelink removal
[AGL/meta-agl.git] / meta-agl-core / conf / local.conf.sample
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. More adventurous users can look at local.conf.extended
6 # which contains other examples of configuration which can be placed in this file
7 # but new users likely won't need any of them initially.
8 #
9 # Lines starting with the '#' character are commented out and in some cases the
10 # default values are provided as comments to show people example syntax. Enabling
11 # the option is a question of removing the # character and making any change to the
12 # variable as required.
13
14 #
15 # Machine Selection
16 #
17 # You need to select a specific machine to target the build with. There are a selection
18 # of emulated machines available which can boot and run in the QEMU emulator:
19 #
20 #MACHINE ?= "qemuarm"
21 #MACHINE ?= "qemuarm64"
22 #MACHINE ?= "qemumips"
23 #MACHINE ?= "qemumips64"
24 #MACHINE ?= "qemuppc"
25 #MACHINE ?= "qemux86"
26 #MACHINE ?= "qemux86-64"
27 #
28 # There are also the following hardware board target machines included for
29 # demonstration purposes:
30 #
31 #MACHINE ?= "beaglebone-yocto"
32 #MACHINE ?= "genericx86"
33 #MACHINE ?= "genericx86-64"
34 #MACHINE ?= "edgerouter"
35 #
36 # This sets the default machine to be qemux86-64 if no other machine is selected:
37 MACHINE ??= "qemux86-64"
38
39 #
40 # Where to place downloads
41 #
42 # During a first build the system will download many different source code tarballs
43 # from various upstream projects. This can take a while, particularly if your network
44 # connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
45 # can preserve this directory to speed up this part of subsequent builds. This directory
46 # is safe to share between multiple builds on the same machine too.
47 #
48 # The default is a downloads directory under TOPDIR which is the build directory.
49 #
50 #DL_DIR ?= "${TOPDIR}/downloads"
51
52 #
53 # Where to place shared-state files
54 #
55 # BitBake has the capability to accelerate builds based on previously built output.
56 # This is done using "shared state" files which can be thought of as cache objects
57 # and this option determines where those files are placed.
58 #
59 # You can wipe out TMPDIR leaving this directory intact and the build would regenerate
60 # from these files if no changes were made to the configuration. If changes were made
61 # to the configuration, only shared state files where the state was still valid would
62 # be used (done using checksums).
63 #
64 # The default is a sstate-cache directory under TOPDIR.
65 #
66 #SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
67
68 #
69 # Where to place the build output
70 #
71 # This option specifies where the bulk of the building work should be done and
72 # where BitBake should place its temporary files and output. Keep in mind that
73 # this includes the extraction and compilation of many applications and the toolchain
74 # which can use Gigabytes of hard disk space.
75 #
76 # The default is a tmp directory under TOPDIR.
77 #
78 #TMPDIR = "${TOPDIR}/tmp"
79
80 #
81 # Default policy config
82 #
83 # The distribution setting controls which policy settings are used as defaults.
84 # The default value is fine for general Yocto project use, at least initially.
85 # Ultimately when creating custom policy, people will likely end up subclassing
86 # these defaults.
87 #
88 DISTRO ?= "poky"
89 # As an example of a subclass there is a "bleeding" edge policy configuration
90 # where many versions are set to the absolute latest code from the upstream
91 # source control systems. This is just mentioned here as an example, its not
92 # useful to most new users.
93 # DISTRO ?= "poky-bleeding"
94
95 #
96 # Package Management configuration
97 #
98 # This variable lists which packaging formats to enable. Multiple package backends
99 # can be enabled at once and the first item listed in the variable will be used
100 # to generate the root filesystems.
101 # Options are:
102 #  - 'package_deb' for debian style deb files
103 #  - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
104 #  - 'package_rpm' for rpm style packages
105 # E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
106 # We default to rpm:
107 PACKAGE_CLASSES ?= "package_rpm"
108
109 #
110 # SDK target architecture
111 #
112 # This variable specifies the architecture to build SDK items for and means
113 # you can build the SDK packages for architectures other than the machine you are
114 # running the build on (i.e. building i686 packages on an x86_64 host).
115 # Supported values are i686 and x86_64
116 #SDKMACHINE ?= "i686"
117
118 #
119 # Extra image configuration defaults
120 #
121 # The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
122 # images. Some of these options are added to certain image types automatically. The
123 # variable can contain the following options:
124 #  "dbg-pkgs"       - add -dbg packages for all installed packages
125 #                     (adds symbol information for debugging/profiling)
126 #  "src-pkgs"       - add -src packages for all installed packages
127 #                     (adds source code for debugging)
128 #  "dev-pkgs"       - add -dev packages for all installed packages
129 #                     (useful if you want to develop against libs in the image)
130 #  "ptest-pkgs"     - add -ptest packages for all ptest-enabled packages
131 #                     (useful if you want to run the package test suites)
132 #  "tools-sdk"      - add development tools (gcc, make, pkgconfig etc.)
133 #  "tools-debug"    - add debugging tools (gdb, strace)
134 #  "eclipse-debug"  - add Eclipse remote debugging support
135 #  "tools-profile"  - add profiling tools (oprofile, lttng, valgrind)
136 #  "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
137 #  "debug-tweaks"   - make an image suitable for development
138 #                     e.g. ssh root access has a blank password
139 # There are other application targets that can be used here too, see
140 # meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
141 # We default to enabling the debugging tweaks.
142 EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
143
144 #
145 # Additional image features
146 #
147 # The following is a list of additional classes to use when building images which
148 # enable extra features. Some available options which can be included in this variable
149 # are:
150 #   - 'buildstats' collect build statistics
151 USER_CLASSES ?= "buildstats"
152
153 #
154 # Runtime testing of images
155 #
156 # The build system can test booting virtual machine images under qemu (an emulator)
157 # after any root filesystems are created and run tests against those images. It can also
158 # run tests against any SDK that are built. To enable this uncomment these lines.
159 # See classes/test{image,sdk}.bbclass for further details.
160 #IMAGE_CLASSES += "testimage testsdk"
161 #TESTIMAGE_AUTO:qemuall = "1"
162
163 #
164 # Interactive shell configuration
165 #
166 # Under certain circumstances the system may need input from you and to do this it
167 # can launch an interactive shell. It needs to do this since the build is
168 # multithreaded and needs to be able to handle the case where more than one parallel
169 # process may require the user's attention. The default is iterate over the available
170 # terminal types to find one that works.
171 #
172 # Examples of the occasions this may happen are when resolving patches which cannot
173 # be applied, to use the devshell or the kernel menuconfig
174 #
175 # Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
176 # Note: currently, Konsole support only works for KDE 3.x due to the way
177 # newer Konsole versions behave
178 #OE_TERMINAL = "auto"
179 # By default disable interactive patch resolution (tasks will just fail instead):
180 PATCHRESOLVE = "noop"
181
182 #
183 # Disk Space Monitoring during the build
184 #
185 # Monitor the disk space during the build. If there is less that 1GB of space or less
186 # than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
187 # shutdown the build. If there is less that 100MB or 1K inodes, perform a hard halt
188 # of the build. The reason for this is that running completely out of space can corrupt
189 # files and damages the build in ways which may not be easily recoverable.
190 # It's necesary to monitor /tmp, if there is no space left the build will fail
191 # with very exotic errors.
192 BB_DISKMON_DIRS ??= "\
193     STOPTASKS,${TMPDIR},1G,100K \
194     STOPTASKS,${DL_DIR},1G,100K \
195     STOPTASKS,${SSTATE_DIR},1G,100K \
196     STOPTASKS,/tmp,100M,100K \
197     HALT,${TMPDIR},100M,1K \
198     HALT,${DL_DIR},100M,1K \
199     HALT,${SSTATE_DIR},100M,1K \
200     HALT,/tmp,10M,1K"
201
202 #
203 # Shared-state files from other locations
204 #
205 # As mentioned above, shared state files are prebuilt cache data objects which can
206 # used to accelerate build time. This variable can be used to configure the system
207 # to search other mirror locations for these objects before it builds the data itself.
208 #
209 # This can be a filesystem directory, or a remote url such as http or ftp. These
210 # would contain the sstate-cache results from previous builds (possibly from other
211 # machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
212 # cache locations to check for the shared objects.
213 # NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
214 # at the end as shown in the examples below. This will be substituted with the
215 # correct path within the directory structure.
216 #SSTATE_MIRRORS ?= "\
217 #file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
218 #file://.* file:///some/local/dir/sstate/PATH"
219
220 #
221 # Yocto Project SState Mirror
222 #
223 # The Yocto Project has prebuilt artefacts available for its releases, you can enable
224 # use of these by uncommenting the following line. This will mean the build uses
225 # the network to check for artefacts at the start of builds, which does slow it down
226 # equally, it will also speed up the builds by not having to build things if they are
227 # present in the cache. It assumes you can download something faster than you can build it
228 # which will depend on your network.
229 #
230 #SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH"
231
232 #
233 # Qemu configuration
234 #
235 # By default native qemu will build with a builtin VNC server where graphical output can be
236 # seen. The line below enables the SDL UI frontend too.
237 PACKAGECONFIG:append:pn-qemu-system-native = " sdl"
238 # By default libsdl2-native will be built, if you want to use your host's libSDL instead of
239 # the minimal libsdl built by libsdl2-native then uncomment the ASSUME_PROVIDED line below.
240 #ASSUME_PROVIDED += "libsdl2-native"
241
242 # You can also enable the Gtk UI frontend, which takes somewhat longer to build, but adds
243 # a handy set of menus for controlling the emulator.
244 #PACKAGECONFIG:append:pn-qemu-system-native = " gtk+"
245
246 #
247 # Hash Equivalence
248 #
249 # Enable support for automatically running a local hash equivalence server and
250 # instruct bitbake to use a hash equivalence aware signature generator. Hash
251 # equivalence improves reuse of sstate by detecting when a given sstate
252 # artifact can be reused as equivalent, even if the current task hash doesn't
253 # match the one that generated the artifact.
254 #
255 # A shared hash equivalent server can be set with "<HOSTNAME>:<PORT>" format
256 #
257 #BB_HASHSERVE = "auto"
258 #BB_SIGNATURE_HANDLER = "OEEquivHash"
259
260 # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
261 # track the version of this file when it was generated. This can safely be ignored if
262 # this doesn't mean anything to you.
263 CONF_VERSION = "2"
264
265 # meta-agl-core uses these variables
266 AGL_FEATURES ?= ""
267 AGL_EXTRA_IMAGE_FSTYPES ?= ""
268
269 DISTRO_FEATURES:append = " systemd "
270 DISTRO_FEATURES_BACKFILL_CONSIDERED:append = " sysvinit"
271 VIRTUAL-RUNTIME_init_manager = "systemd"
272
273 # soon: INIT_MANAGER = "systemd"