summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorSamuli Piippo <samuli.piippo@digia.com>2013-04-28 19:19:17 +0300
committerSamuli Piippo <samuli.piippo@digia.com>2013-04-30 08:48:05 +0300
commitd0a877bb1f84ca12dd299971b9322e5753d3ee8f (patch)
tree670797dd9ae2da6cb7ad28a30cb827278a17d64f
parentf63cf1b70fb31413a8f02728f119214fb865fff2 (diff)
downloadmeta-boot2qt-d0a877bb1f84ca12dd299971b9322e5753d3ee8f.tar.gz
Create new meta layer and distro for B2Qt on embedded Linux
Change-Id: I0dccd0d118b95cf2a5aa39cf5fcdbf69787630a4 Reviewed-by: Kalle Viironen <kalle.viironen@digia.com>
-rw-r--r--README31
-rw-r--r--conf/bblayers.conf.sample20
-rw-r--r--conf/distro/b2qt.conf23
-rw-r--r--conf/layer.conf11
-rw-r--r--conf/local.conf.sample258
5 files changed, 343 insertions, 0 deletions
diff --git a/README b/README
new file mode 100644
index 0000000..c642c1c
--- /dev/null
+++ b/README
@@ -0,0 +1,31 @@
1OpenEmbedded/Yocto meta layer for B2Qt on embedded Linux
2==========================================================
3
4This layer provides B2Qt on embedded Linux recipes for use with
5OpenEmbedded and Yocto.
6
7This layer depends on:
8
9URI: git://git.openembedded.org/openembedded-core
10branch: master
11revision: HEAD
12
13URI: git://git.openembedded.org/meta-openembedded
14layer: meta-oe
15branch: master
16revision: HEAD
17
18URI: git://git.yoctoproject.org/meta-ti
19branch: master
20revision: HEAD
21
22URI: git://git.yoctoproject.org/meta-fsl-arm
23branch: master
24revision: HEAD
25
26URI: git://git.yoctoproject.org/meta-fsl-arm-extra
27branch: master
28revision: HEAD
29
30Main layer maintainer: Samuli Piippo <samuli.piippo@digia.com>
31
diff --git a/conf/bblayers.conf.sample b/conf/bblayers.conf.sample
new file mode 100644
index 0000000..2ec582e
--- /dev/null
+++ b/conf/bblayers.conf.sample
@@ -0,0 +1,20 @@
1# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
2# changes incompatibly
3LCONF_VERSION = "6"
4
5BBPATH = "${TOPDIR}"
6BBFILES ?= ""
7
8BBLAYERS ?= " \
9 ##COREBASE##/meta \
10 ##COREBASE##/meta-yocto \
11 ##COREBASE##/meta-fsl-arm \
12 ##COREBASE##/meta-fsl-arm-extra \
13 ##COREBASE##/meta-ti \
14 ##COREBASE##/meta-openembedded/meta-oe \
15 ##COREBASE##/meta-b2qt \
16 "
17BBLAYERS_NON_REMOVABLE ?= " \
18 ##COREBASE##/meta \
19 ##COREBASE##/meta-yocto \
20 "
diff --git a/conf/distro/b2qt.conf b/conf/distro/b2qt.conf
new file mode 100644
index 0000000..0f94be0
--- /dev/null
+++ b/conf/distro/b2qt.conf
@@ -0,0 +1,23 @@
1include conf/distro/poky.conf
2
3DISTRO = "b2qt"
4DISTRO_NAME = "B2Qt on embedded Linux"
5DISTRO_VERSION = "1.1"
6SDK_VERSION := "${DISTRO_VERSION}"
7
8MAINTAINER = "QtCommercial <QtCommercial@digia.com>"
9
10SANITY_TESTED_DISTROS += " \
11 Ubuntu 11.04 \n \
12 LinuxMint-14 \n \
13 "
14
15IMAGE_FSTYPES = "tar.gz"
16
17SYSVINIT_ENABLED_GETTYS = ""
18
19DISTRO_FEATURES ?= "alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc ${DISTRO_FEATURES_LIBC}"
20
21COMMERCIAL_AUDIO_PLUGINS ?= "gst-plugins-ugly-mad gst-plugins-ugly-mpegaudioparse"
22COMMERCIAL_VIDEO_PLUGINS ?= "gst-plugins-ugly-mpeg2dec gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
23
diff --git a/conf/layer.conf b/conf/layer.conf
new file mode 100644
index 0000000..9e97746
--- /dev/null
+++ b/conf/layer.conf
@@ -0,0 +1,11 @@
1# We have a conf and classes directory, append to BBPATH
2BBPATH .= ":${LAYERDIR}"
3
4# We have a recipes directory, add to BBFILES
5BBFILES += "${LAYERDIR}/recipes*/*/*.bb \
6 ${LAYERDIR}/recipes*/*/*.bbappend \
7 "
8
9BBFILE_COLLECTIONS += "b2qt"
10BBFILE_PATTERN_b2qt := "^${LAYERDIR}/"
11BBFILE_PRIORITY_b2qt = "20"
diff --git a/conf/local.conf.sample b/conf/local.conf.sample
new file mode 100644
index 0000000..fe1627f
--- /dev/null
+++ b/conf/local.conf.sample
@@ -0,0 +1,258 @@
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# Parallelism Options
16#
17# These two options control how much parallelism BitBake should use. The first
18# option determines how many tasks bitbake should run in parallel:
19#
20BB_NUMBER_THREADS = "4"
21#
22# The second option controls how many processes make should run in parallel when
23# running compile tasks:
24#
25PARALLEL_MAKE = "-j 4"
26#
27# For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would
28# be appropriate for example.
29
30#
31# Machine Selection
32#
33# You need to select a specific machine to target the build with. There are a selection
34# of emulated machines available which can boot and run in the QEMU emulator:
35#
36#MACHINE ?= "qemuarm"
37#MACHINE ?= "qemumips"
38#MACHINE ?= "qemuppc"
39#MACHINE ?= "qemux86"
40#MACHINE ?= "qemux86-64"
41#
42# There are also the following hardware board target machines included for
43# demonstration purposes:
44#
45#MACHINE ?= "atom-pc"
46#MACHINE ?= "beagleboard"
47#MACHINE ?= "mpc8315e-rdb"
48#MACHINE ?= "routerstationpro"
49#
50# This sets the default machine to be qemux86 if no other machine is selected:
51MACHINE ??= "qemux86"
52
53#
54# Where to place downloads
55#
56# During a first build the system will download many different source code tarballs
57# from various upstream projects. This can take a while, particularly if your network
58# connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
59# can preserve this directory to speed up this part of subsequent builds. This directory
60# is safe to share between multiple builds on the same machine too.
61#
62# The default is a downloads directory under TOPDIR which is the build directory.
63#
64#DL_DIR ?= "${TOPDIR}/downloads"
65
66PREMIRRORS = "http://qt-rnd.it-local/yocto/"
67
68
69#
70# Where to place shared-state files
71#
72# BitBake has the capability to accelerate builds based on previously built output.
73# This is done using "shared state" files which can be thought of as cache objects
74# and this option determines where those files are placed.
75#
76# You can wipe out TMPDIR leaving this directory intact and the build would regenerate
77# from these files if no changes were made to the configuration. If changes were made
78# to the configuration, only shared state files where the state was still valid would
79# be used (done using checksums).
80#
81# The default is a sstate-cache directory under TOPDIR.
82#
83#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
84
85#
86# Where to place the build output
87#
88# This option specifies where the bulk of the building work should be done and
89# where BitBake should place its temporary files and output. Keep in mind that
90# this includes the extraction and compilation of many applications and the toolchain
91# which can use Gigabytes of hard disk space.
92#
93# The default is a tmp directory under TOPDIR.
94#
95#TMPDIR = "${TOPDIR}/tmp"
96
97#
98# Default policy config
99#
100# The distribution setting controls which policy settings are used as defaults.
101# The default value is fine for general Yocto project use, at least initially.
102# Ultimately when creating custom policy, people will likely end up subclassing
103# these defaults.
104#
105DISTRO ?= "b2qt"
106# As an example of a subclass there is a "bleeding" edge policy configuration
107# where many versions are set to the absolute latest code from the upstream
108# source control systems. This is just mentioned here as an example, its not
109# useful to most new users.
110# DISTRO ?= "poky-bleeding"
111
112#
113# Package Management configuration
114#
115# This variable lists which packaging formats to enable. Multiple package backends
116# can be enabled at once and the first item listed in the variable will be used
117# to generate the root filesystems.
118# Options are:
119# - 'package_deb' for debian style deb files
120# - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
121# - 'package_rpm' for rpm style packages
122# E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
123# We default to rpm:
124PACKAGE_CLASSES ?= "package_rpm"
125
126#
127# SDK/ADT target architecture
128#
129# This variable specified the architecture to build SDK/ADT items for and means
130# you can build the SDK packages for architectures other than the machine you are
131# running the build on (i.e. building i686 packages on an x86_64 host._
132# Supported values are i686 and x86_64
133#SDKMACHINE ?= "i686"
134
135#
136# Extra image configuration defaults
137#
138# The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
139# images. Some of these options are added to certain image types automatically. The
140# variable can contain the following options:
141# "dbg-pkgs" - add -dbg packages for all installed packages
142# (adds symbol information for debugging/profiling)
143# "dev-pkgs" - add -dev packages for all installed packages
144# (useful if you want to develop against libs in the image)
145# "ptest-pkgs" - add -ptest packages for all ptest-enabled packages
146# (useful if you want to run the package test suites)
147# "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
148# "tools-debug" - add debugging tools (gdb, strace)
149# "eclipse-debug" - add Eclipse remote debugging support
150# "tools-profile" - add profiling tools (oprofile, exmap, lttng, valgrind)
151# "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
152# "debug-tweaks" - make an image suitable for development
153# e.g. ssh root access has a blank password
154# There are other application targets that can be used here too, see
155# meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
156# We default to enabling the debugging tweaks.
157EXTRA_IMAGE_FEATURES = "debug-tweaks"
158
159#
160# Additional image features
161#
162# The following is a list of additional classes to use when building images which
163# enable extra features. Some available options which can be included in this variable
164# are:
165# - 'buildstats' collect build statistics
166# - 'image-mklibs' to reduce shared library files size for an image
167# - 'image-prelink' in order to prelink the filesystem image
168# - 'image-swab' to perform host system intrusion detection
169# NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
170# NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
171USER_CLASSES ?= "buildstats image-mklibs image-prelink"
172
173#
174# Runtime testing of images
175#
176# The build system can test booting virtual machine images under qemu (an emulator)
177# after any root filesystems are created and run tests against those images. To
178# enable this uncomment this line
179#IMAGETEST = "qemu"
180#
181# This variable controls which tests are run against virtual images if enabled
182# above. The following would enable bat, boot the test case under the sanity suite
183# and perform toolchain tests
184#TEST_SCEN = "sanity bat sanity:boot toolchain"
185#
186# Because of the QEMU booting slowness issue (see bug #646 and #618), the
187# autobuilder may suffer a timeout issue when running sanity tests. We introduce
188# the variable TEST_SERIALIZE here to reduce the time taken by the sanity tests.
189# It is set to 1 by default, which will boot the image and run cases in the same
190# image without rebooting or killing the machine instance. If it is set to 0, the
191# image will be copied and tested for each case, which will take longer but be
192# more precise.
193#TEST_SERIALIZE = "1"
194
195#
196# Interactive shell configuration
197#
198# Under certain circumstances the system may need input from you and to do this it
199# can launch an interactive shell. It needs to do this since the build is
200# multithreaded and needs to be able to handle the case where more than one parallel
201# process may require the user's attention. The default is iterate over the available
202# terminal types to find one that works.
203#
204# Examples of the occasions this may happen are when resolving patches which cannot
205# be applied, to use the devshell or the kernel menuconfig
206#
207# Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
208# Note: currently, Konsole support only works for KDE 3.x due to the way
209# newer Konsole versions behave
210#OE_TERMINAL = "auto"
211# By default disable interactive patch resolution (tasks will just fail instead):
212PATCHRESOLVE = "noop"
213
214#
215# Disk Space Monitoring during the build
216#
217# Monitor the disk space during the build. If there is less that 1GB of space or less
218# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
219# shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort
220# of the build. The reason for this is that running completely out of space can corrupt
221# files and damages the build in ways which may not be easily recoverable.
222BB_DISKMON_DIRS = "\
223 STOPTASKS,${TMPDIR},1G,100K \
224 STOPTASKS,${DL_DIR},1G,100K \
225 STOPTASKS,${SSTATE_DIR},1G,100K \
226 ABORT,${TMPDIR},100M,1K \
227 ABORT,${DL_DIR},100M,1K \
228 ABORT,${SSTATE_DIR},100M,1K"
229
230#
231# Shared-state files from other locations
232#
233# As mentioned above, shared state files are prebuilt cache data objects which can
234# used to accelerate build time. This variable can be used to configure the system
235# to search other mirror locations for these objects before it builds the data itself.
236#
237# This can be a filesystem directory, or a remote url such as http or ftp. These
238# would contain the sstate-cache results from previous builds (possibly from other
239# machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
240# cache locations to check for the shared objects.
241# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
242# at the end as shown in the examples below. This will be substituted with the
243# correct path within the directory structure.
244#SSTATE_MIRRORS ?= "\
245#file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
246#file://.* file:///some/local/dir/sstate/PATH"
247
248# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
249# track the version of this file when it was generated. This can safely be ignored if
250# this doesn't mean anything to you.
251CONF_VERSION = "1"
252
253INHERIT += "rm_work"
254
255BBMASK = "meta-ti/recipes-misc"
256ACCEPT_FSL_EULA = "1"
257LICENSE_FLAGS_WHITELIST = "commercial"
258