--- /dev/null
+ 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:
+
+TaskFailed:
+TaskSucceeded:
+
+ The task status event classes have a 'task' attribute, which is
+simply a string containing the task which succeeded or failed. They also
+have a 'data' attribute, which contains the environment data of the package
+in question.
+
+PackageSucceeded:
+PackageFailed:
+
+ 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).
+
+
+TODO:
+TaskStart
+PackageStart
+UnsatisfiedDep
+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.
TODO:
-[x] Pester schurig
- [x] What is the dir/envvar we use to hold outputted files for packaging?
- ala the current ipktmpdir.
- Doesnt matter.
- [x] Env var names for the 3 dependency forms, build depends - target, build depends - build, depends.
- DEPENDS - build, RDEPENDS - runtime
- reflect build machine build depends using seperate build .oe files.
-
[x] oe package
[x] Update .oe and .conf parsers to not strip out all the tabs in our
python function vars..
data and parse methods.
[ ] API Sanity Audit.
[ ] Comment/Docs Audit.
+ [ ] Allow user supply of .oeclasses to be inherited in every file that
+ gets parsed via the INHERITS variable.
[ ] oebuild and oemake
[ ] Teach the system to support grabbing OEFILES from upstream