These enabled options to be specified in the form:
PACKAGECONFIG ?? = "<default options>"
PACKAGECONFIG[foo] = "--enable-foo,--disable-foo,foo_depends,foo_runtime_depends"
So that DEPENDS, RDEPENDS_${PN} and EXTRA_OECONF can be automatically
built from specific options. Those options can easily be customised
by the distro config or the user.
Based on some ideas from Chris Elston <celston@katalix.com> but with
an improved easier to use one line interface.
(From OE-Core rev: 7a58911f6951abd56db9ebb37f8d6284d91fa514)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
patch depends on unpack
configure depends on patch
We simply don't need a configure dependency on unpack. This simplifies
the dependencies of every recipe slightly and should make bitbake
slightly faster at resovling dependency graphs.
It also makes the .dot dependency graphs slightly more readable by
removing noise.
(From OE-Core rev: c54c1280fc0d06a53e23339c3913ec88eead13d9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code displaying console events has been handled by the bitbake
UI since 1.8 so the legacy code path can be removed. If a log event
is wanted, there are much better (and more complete) ways to do this
so remove the EVENTLOG code too.
(From OE-Core rev: aa60484384385a8b0f07e8062d58056a3670e399)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With Richard's commit f9c36392, we only build one kernel for a system,
thus we shouldn't extend PREFERRED_PROVIDER for virtual/kernel.
[YOCTO #1471]
(From OE-Core rev: 90ad70fe13a9f8409387ca70289998bdca649aeb)
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, if for example you had a package called "mx", and a second
package called "libomxil" listed in COMMERCIAL_LICENSE (without mx being
listed there), it would match mx as being commercially licensed because
mx is a substring of libomxil. Fix the search to ensure it only matches
the listed package name exactly.
(From OE-Core rev: b23e51e6c961cf3f7e2aaf89648fecce78424c99)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change to a proper sentence and add a reference to the
COMMERCIAL_LICENSE variable so that the user knows where this can be
controlled.
Addresses remainder of [YOCTO #846]
(From OE-Core rev: 463d1719cc627ef22089282acfe70d7fcb835419)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes debugging the new tune code easier since it doesn't involve staring at 'bitbake -e' output anymore.
(From OE-Core rev: c1903b1221e9b419aefe49e40a8acd61575de797)
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This means if PKGARCHCOMPAT_ARMV7A is set, "armv7a-vfp-neon" is renamed
to be "armv7a". Other compatibility mappings can be added as needed.
(From OE-Core rev: 08c0b7060009113e8dffdef51ff6b9b4b7f28894)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The problem occured when unzip-native is not yet staged, and ZIP
archive unpacking already started resulting in failed do_unpack task.
(oe.dev has a NEED_UNZIP_FOR_UNPACK variable we did not bring over)
[RP: Use srcuri from already existing variable]
(From OE-Core rev: 6ca80453618fa308cc2d6329450aaf5dfdf2d610)
Signed-off-by: Ihar Hrachyshka <ihar.hrachyshka@gmail.com>
Signed-off-by: Koen Kooi <koen@openembedded.org>
Signed-off-by: Tom Rini <tom_rini@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recent versions of qemu seem to be happy enough building with gcc 4.x, and indeed most modern distributions aren't shipping gcc3 any more, so there is no point checking for its presence as part of sanity.
Also remove the check_gcc3 function from base since nothing else uses it.
(From OE-Core rev: ec5c68e9368111bd51c1cfd6a9a135c53b82ceca)
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch removes METADATA_BRANCH and METADATA_REVISION, and treats the meta/
in the same way as other layers.
In the case some layers belonging to the same repo, the branch and revision
are only printed once, but all the layer names are still printed.
An example output can be:
OE Build Configuration:
BB_VERSION = "1.13.1"
TARGET_ARCH = "i586"
TARGET_OS = "linux"
MACHINE = "emenlow"
DISTRO = "poky"
DISTRO_VERSION = "1.0+snapshot-20110702"
TARGET_FPU = ""
meta
meta-yocto = "dcui/banner_v3:4b712dba68a98c827b8f3d0242da9153c4f65473"
meta-emenlow
meta-sugarbay
meta-n450 = "dcui/test1:76d1178ba1a43cf6457c89717134aeb9f1275fae"
(From OE-Core rev: f271498638a9da271ed5da973666fe4a7bd0ac63)
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Set 'CCACHE_DIR' in 'bitbake.conf' and create the dirs for every
package before task 'do_configure' started.
[RP: Merge dirs variables into one]
(From OE-Core rev: fe03f78fb0bf7d54b9472832e43764e882f918a1)
Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bitbake now allows the umask to be specified per task. The
following tasks will have a umask of 022 set by default:
do_configure
do_compile
do_install
do_package
do_populate_sysroot
do_rootfs
do_configure and do_compile need a umask of 022 set because -many- recipes
directly copy generated files out of recipe's build directory. Instead of
fixing each existing and future recipe, it was shown to be much easier to
just set the umask.
(From OE-Core rev: 0cfa7ebcf661aa0645c6d4d858b04946ebacb7e4)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the only way to get anything to build is to set USE_NLS="yes"
for glib-2.0. We might as well do this in the recipe by default for
now and simpllify the code.
The magic handling of USE_NLS_<recipename> is also removed since this
can be done in the form USE_NLS_pn-<recipename> using overrides these
days.
(From OE-Core rev: 2e3727b05ae58aaf1eed88967c13cae085e7a702)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Add support for using SOC_FAMILY in the COMPATIBLE_MACHINES
setting for a recipe.
* This will allow recipes to work for entire families of
devices without having to maintain/update the compatible
devices as new devices are added into a family
Based on 07076390358f211bd96779bec2d6eb5eaa0ad699 by Chase Maupin <chase.maupin@ti.com>
(From OE-Core rev: dc303cbf25cf48aa98ff1979882820dd25f8cd9d)
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This massively cleans up the dependency handling in the two classes
when interacting with BBCLASSEXTEND.
This change has a dependency on the bitbake override handling change
and also the existence of the RecipePreFinalise event.
(From OE-Core rev: f183c7cfe377fa6ed2777605c3590a9dda2060df)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* sometimes it's usefull to remove only sstate cache and keep downloaded sources for rebuild
(From OE-Core rev: e071bc9982fc3ace3a32a990905884929392c4b6)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This includes some utility functions for dealing with groups of packages
defined in the metadata. Metadata syntax:
PACKAGE_GROUP_<group> = "<list of packages>"
If the packages in the group are optional:
PACKAGE_GROUP_<group>[optional] = "1"
(From OE-Core rev: 4df212e9c2a1dd7c80d180fd13b67e9f2799d3e1)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This can be useful if we need the imports from another config parsed event
handler, and can't rely upon the base one running before that one.
(From OE-Core rev: dc579ce4dcf9a3743ced9eae4fe510a079961faf)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current mechanism makes it easier for classes to add new oe modules to be
automatically imported, and thereby made available to python snippets (${@}).
(From OE-Core rev: 0c560a2a7954412f714db86b1aaadb7acbe72d1b)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This implementation consists of two components:
- Type creation python modules, whose job it is to construct objects of the
defined type for a given variable in the metadata
- typecheck.bbclass, which iterates over all configuration variables with a
type defined and uses oe.types to check the validity of the values
This gives us a few benefits:
- Automatic sanity checking of all configuration variables with a defined type
- Avoid duplicating the "how do I make use of the value of this variable"
logic between its users. For variables like PATH, this is simply a split(),
for boolean variables, the duplication can result in confusing, or even
mismatched semantics (is this 0/1, empty/nonempty, what?)
- Make it easier to create a configuration UI, as the type information could
be used to provide a better interface than a text edit box (e.g checkbox for
'boolean', dropdown for 'choice')
This functionality is entirely opt-in right now. To enable the configuration
variable type checking, simply INHERIT += "typecheck". Example of a failing
type check:
BAZ = "foo"
BAZ[type] = "boolean"
$ bitbake -p
FATAL: BAZ: Invalid boolean value 'foo'
$
Examples of leveraging oe.types in a python snippet:
PACKAGES[type] = "list"
python () {
import oe.data
for pkg in oe.data.typed_value("PACKAGES", d):
bb.note("package: %s" % pkg)
}
LIBTOOL_HAS_SYSROOT = "yes"
LIBTOOL_HAS_SYSROOT[type] = "boolean"
python () {
import oe.data
assert(oe.data.typed_value("LIBTOOL_HAS_SYSROOT", d) == True)
}
(From OE-Core rev: a04ce490e933fc7534db33f635b025c25329c564)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PRINC which should add to base PR value has a problem when
the PR is single digit e.g. r0 - r9. Current algorithm
needed atleasts 2 digits to successfully populate end and begin
markers.
We reimplement the incrementing algorithm using regular expressions
which addressed the above mentioned problem and
simplifies the logic a bit and gets rid of loops and conditionals
(From OE-Core rev: 9aeaae7b786a42d213ad4224743dfd49e2324077)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new logging.bbclass replaces the oe* logging functions with bb* equivalents.
There are no longer any users of the oe* API within oe-core. Remove the oe*
functions.
(From OE-Core rev: 168d94be0e28fcbefda9df07d6d1b0cfd96e75fc)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new bash logging class provides bbnote, bbwarn, bbfatal, and bbdebug
replacements (as well as bbplain and bberror) for the oe* equivalents. Use the
new bb* API in preparation to delete the oe* logging API.
This patch was automatically generated by a sed script. The result has been
visually inspected and used to build core-image-sato for qemux86.
(From OE-Core rev: a1f09fce5caba389d0484b169f0cde85d64514fa)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The following logging mechanisms are to be used in bash functions of recipes.
They are intended to map one to one in intention and output format with the
python recipe logging functions of a similar naming convention: bb.plain(),
bb.note(), etc.
For the time being, all of these print only to the task logs. Future
enhancements may integrate these calls with the bitbake logging infrastructure,
allowing for printing to the console as appropriate. The interface and intention
statements reflect that future goal. Once it is in place, no changes will be
necessary to recipes using these logging mechanisms.
I opted to write new functions instead of modifying the oe* logging functions
from base.bbclass (and utils.bbclass in oe) for a couple reasons. First, one of
my goals was to generate a uniform logging API between bash and python in
recipes. Second, there are no users of oe* logging in meta (oe-core) or
meta-yocto, while several oe recipes do use them. I wanted to make a clean start
with the freedom to change behavior without forcing the oe recipes to change or
experience unexpected logging changes. Eventually, the oe recipes can be
migrated to the new bb* logging routines and the existing oe* routines can be
retired (deleted).
(From OE-Core rev: 7cb3f0206619b725e404282fa7a3ac50b4609f1e)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Cc: Chris Larson <clarson@kergoth.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When the existing test for loglevel fails, the syntax used results in the recipe
exiting with a silent failure. Performing any bash command after the test block
resolves the problem, such as "shift" or "echo ''". Rewriting with 'if []; then'
blocks provides a cleaner syntax and also resolves the failure.
(From OE-Core rev: 5857516404411040598b69c85d184ccdfc0af2e0)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The do_setscene task only exists for rebuild support now as all its other
functionality has been superceeded. The rebuild task currently crashes due
to removal of the working directory and therefore isn't working for anyone.
It also interacts extremely badly with the newer sstate technology to the
point of being dangerous.
Summary, if we want rebuild support it needs a reimplementation so remove
this version and all its remnants and hacks.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This create a clean() method in each of the fetcher modules
and correctly cleans the .done stamp file and lock files
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Fixes "multiple repeat" or "nothing to repeat" errors when parsing recipes
with '++' in the file name.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
This patch intend to fix the random unpack failure of linux-libc-headers-yocto
and linux-yocto.
The root cause of the unpack failure is that: these two recpies has the same URL, thus
has the same dest file during the fetch and unpack phase:
do_fetch : create tar ball ${DL_DIR}/git_git.pokylinux.org.linux-yocto-2.6.37.tar.gz
do_unpack : extract tar ball ${DL_DIR}/git_git.pokylinux.org.linux-yocto-2.6.37.tar.gz
fetch phase is protected by lockfile, so it works fine. but unpack phase is not lock protected,
thus there is race condition like: when linux-yocto do_unpack is extracting the tar ball,
linux-libc-headers-yocto do_fetch starts to create tar ball thus overwrite linux-yocto's
tar ball and cause linux-yocto do_unpack failure
To fix this issue, do_unpack also need to be protected by lock
Signed-off-by: Yu Ke <ke.yu@intel.com>
Richard Purdie
Saul Wold
Dongxiao Xu
Paul Eggleton
Koen Kooi
Ihar Hrachyshka
Phil Blundell
Dexuan Cui
Wenzong Fan
Mark Hatle
Martin Jansa
Chris Larson
Khem Raj
Darren Hart
Beth Flanagan
Yu Ke
Richard Purdie