blob: a41693b272cd9d89674d12ec7ad8f164cdb6fd41 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
The OpenEmbedded build infrastructure now has a fairly sane event
handling core. The following are the events which get fired at
appropriate points during the build process:
TaskStarted:
TaskFailed:
TaskSucceeded:
The task status event classes have a 'task' attribute, which is
simply a string containing the task to which this event applies. They also
have a 'data' attribute, which contains the environment data of the package
in question.
PkgStarted:
PkgSucceeded:
PkgFailed:
The package build status event classes are a bit higher level. That
is, they reflect the overall build status of a given package as a whole, without
the task level breakdown. The 'package' attribute is a string which contains
the package which failed, in the usual form (i.e. content/glibc-2.3.1-r0).
UnsatisfiedDep:
This event is triggered by oemake whenever an unsatisfied dependency
is encountered on a package we're attempting to build. It will remove the
package from the build, and every package that directly or indirectly depends
on the package that encountered this problem.
Handling:
Any .oe or .oeclass can register an event handler. It is simply
'addhandler <variable> [<othervariable> <anothervariable> ...]'. The
variable in question must be flagged as a block of python code, and, due
to the way in which it spawns the code, must be indented by an extra tab.
See the base.oeclass for our base event handler as an example.
TODO:
RecursiveDep
MultipleProviders
Add 'log' data to the task and package builds, which contains the stdout and
stderr of the task/package which succeeded/failed, so that email notifications
of failures can include the build log.
|
