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
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
|
TODO:
[x] oe package
[ ] Define CONFIG_SITE to point to a "SYS" specific config.site.
[ ] .oe needs access to PROVIDES information that oemake is
currently populating. Move the default set of the .oe
provides into the .oe parser rather than oemake.
[ ] Remove duplicated implementations, and convert everyone to the new
data and parse methods.
[ ] API Sanity Audit.
[ ] Comment/Docs Audit.
[.] Implement API testing using doctest.
[ ] Alter 'export' handling, to support exporting a var without
defining the variable.
format:
export [VAR[=value] ...]
[ ] Possibility: alternate data formats for metadata (i.e. arrays).
i.e. THIS[1] = "that"
THIS["heh"] = "that"
[ ] More complex variable setting/conditionals
Options:
[ ] Add support for 'anonymous' OE functions in .oe{,class} files.
These functions are to be executed immediately at parse time,
thereby giving one the ability to exert more control over the set
of variables.
[ ] if/elseif/else/endif blocks for conditional variable setting
[ ] Split oemake's knowledge of AVAILABLE OEFILES from its
knowledge of which packages are to be built.
[ ] Define structure and data exchange format(s) for
upstream OE metadata repositories.
Possibly follow an 'apt-get' style. Cache the
metadata locally, with a command to update.
[ ] Make Fetch use md5 hashing to indicate per-file download success.
Or in the case of downloaded directories (cvs/svn/bk), simply a
success stamp on a per file basis.
[ ] Add "noinherit", as a means of removing an item from the
list of classes to inherit.
[ ] Need a way to specify that you cannot build a given .oe,
from the .oe. Along the lines of portage's ability for
an ebuild to specify that it isnt buildable for a given
architecture or set of architectures.
[ ] Write helper functions ala ebuild's dobin/dodoc/etc and debian's dh_*.
[ ] Note, if we do this using actual commands within the .oe file
as opposed to shell helpers, the buildsystem is then aware
of what files are libs, what are includes, etc, and we could
then do a sane automatic population of staging based on that
information.
[ ] Metadata exchange through multiple oebuild/oemake/oespawn executions
(i.e. to set qpedir/qtdir for all builds from the qt/opie/qtopia .oe's)
[ ] Split staging by package
[ ] When a package populates staging, create links for every item
that this .oe Provides.
[ ] Wouldnt be a bad idea to make use of update-alternatives
to manage buildroot's staging links, thereby allowing us
to deal with multiple provides sanely (priority).
[ ] More complex set of FLAGS vars, to account for the various DEPENDS.
[ ] Example:
ipkg depends on virtual/libc, puts staging_dir/libc in flags.
glibc staging creates symlinks for every atom it PROVIDES,
and installs its staging files into the glibc-ver-rev dir.
[ ] Revamp category handling
[ ] oebuild
[ ] Implement and test check_md5, taking nostamp into account.
[ ] Add '--undo'/'-u' cmdline opt that calls the 'undo' task
for the supplied task.
[ ] Add '--rebuild'/'-r' cmdline opt that calls the 'undo' task
for the entire upward path in the digraph, then builds that task.
(same thing done when the md5 changes on an affected var in
check_md5)
[.] oemake
[ ] Check for recursive dependency
[ ] Deal with multiple provides
[.] oemaked
[ ] Monitor the stamps for a given .oe file as well, to ensure
changes in build state as well as changes to build metadata result
in a rebuild.
[ ] oerootfs
[ ] oeimage
[ ] packages
[ ] add cross binutils and binutils
[ ] add gcc
[ ] figure out where to put the glibc install into the toolchain dir,
which is only needed by gcc pass 2.
[ ] add qtopia 1.6.1
[.] add qt 2.3.6
[ ] convert packages from OpenZaurus buildroot
[ ] New c++ OE library (possibility -- open to debate)
Benefits:
* Newly architected with no remnant cruft from portage.
* Easier bindings for non-python tools that utilize OE.
* Use existing fetch routines from apt-get.
* Easier use of libkconfig.
Liabilities:
* Development time / Wheel reinvention
* Extra effort involved in adding python scripting support
[ ] .oe lex/yacc (flex/bison) parser
[ ] OE metadata data structure(s) for storage in RAM
[ ] Code execution, status and event handling
[ ] Build
'----Package
'----Task
[ ] Fetching things from upstream
[ ] Possibly utilize apt-get "methods"
[ ] CVS method
[ ] BK method
[ ] SVN method
[ ] Shared mem interface to control autobuild daemon
[ ] XML/RPC metadata exchange format
[ ] Cross process metadata exchange with and without a metadata daemon
|
