linux/meta-openembedded.git/meta-oe/classes, branch dizzy

meta-oe: use BPN in SRC_URI

2014-07-15T12:56:55+00:00

Fixed SRC_URI: * ${PN} -> ${BPN}, use ${BP} if it was ${PN}-${PV} * ${P} -> ${BP} Otherwise we would meet do_fetch errors when we do the multilib, native or nativesdk build. Signed-off-by: Robert Yang Signed-off-by: Martin Jansa

breakpad.bbclass: set includedir in CXXFLAGS

2014-05-03T18:45:03+00:00

Previously this was only set in CFLAGS. An build issue was discovered while convering in internal application from Qt4 to Qt5. As a result of this, the required header files were no longer found, until we also set CXXFLAGS. Signed-off-by: Anders Darander Signed-off-by: Martin Jansa

breakpad: add initial recipe

2013-10-21T10:15:03+00:00

Breakpad is an open-source multi-platform crash reporting system. Apart from the breakpad recipe, add a bbclass for applications that want to use this library. This bbclass will set up the include path and also generate the symbol file. Signed-off-by: Anders Darander Signed-off-by: Martin Jansa

classes/vala: remove

2013-09-03T17:12:37+00:00

This is now in OE-Core as of 807285c751862aaa775db5a13293007bfb3c29df. Signed-off-by: Paul Eggleton Signed-off-by: Martin Jansa

recipes: Unify indentation

2013-04-15T14:23:17+00:00

* This change is only aesthetic (unlike indentation in Python tasks). * Some recipes were using tabs. * Some were using 8 spaces. * Some were using mix or different number of spaces. * Make them consistently use 4 spaces everywhere. * Yocto styleguide advises to use tabs (but the only reason to keep tabs is the need to update a lot of recipes). Lately this advice was also merged into the styleguide on the OE wiki. * Using 4 spaces in both types of tasks is better because it's less error prone when someone is not sure if e.g. do_generate_toolchain_file() is Python or shell task and also allows to highlight every tab used in .bb, .inc, .bbappend, .bbclass as potentially bad (shouldn't be used for indenting of multiline variable assignments and cannot be used for Python tasks). * Don't indent closing quote on multiline variables we're quite inconsistent wheater it's first character on line under opening quote or under first non-whitespace character in previous line. Signed-off-by: Martin Jansa Acked-by: Koen Kooi

update-fonts.bbclass: remove - we now use oe-core's fontcache.bbclass

2013-02-16T04:52:37+00:00

Signed-off-by: Andreas Müller Signed-off-by: Martin Jansa

ttf: introduce update-fonts bbclass and change all ttf recipes to use it

2013-02-06T14:16:01+00:00

* without this ttf.inc had to set RRECOMMENDS and postinst/postrm without PN suffix to cover all subpackages created in ttf recipes Signed-off-by: Martin Jansa

gitpkgv.bbclass: cache GITPKGV result

2013-01-18T09:49:44+00:00

gitpkgv runs the 'git rev-list | wc -l' several times when processing a package using GITPKGV. This takes ages for packages like the linux kernel which has a) a large repository and b) lots of subpackages. This patch caches the result of 'git rev-list' and uses it on the next run. Signed-off-by: Enrico Scholz Signed-off-by: Martin Jansa

kernel bbclass: delete

2012-11-29T10:03:35+00:00

Signed-off-by: Koen Kooi

kernel.bbclass: remove explicit version.h target

2012-11-13T17:36:45+00:00

The compilation routine for the kernel has an explicit call to build version.h, which works fine for most kernels, but the location of it has recently changes. commit d183e6f5 [UAPI: Move linux/version.h] commit 10b63956 [UAPI: Plumb the UAPI Kbuilds into the user header installation and checking] moves the file to include/generated/linux/version.h and then to include/generated/uapi/linux/version.h. As a result kernel builds of 3.7 or bisection builds of intermediate kernel commits will fail with: make[2]: *** No rule to make target `include/linux/version.h'. Stop. Making the explicit version.h build conditional on the version, or via a file test would fix the problem, but it introduces some complexity to the build. Even without an explicit call to build version.h, it is always produced by the kernel build, so it can simply be removed. This extra make line was originally so that the kernel version could be determined, so that then different instructions could be executed depending on whether it was a 2.4 or 2.6 kernel. Since we no longer support 2.4, this code is no longer needed. [YOCTO: #3293] Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie