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
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
TODO:
[x] oe package
[ ] Remove duplicated implementations, and convert everyone to the new
data and parse methods.
[ ] API Sanity Audit.
[ ] Comment/Docs Audit.
[.] Implement API testing using doctest.
[x] BUG: If we only run an update_data after a load of an .oe,
but not for a .oeclass, if multiple .oeclasses define, say, for
example DEPENDS_prepend, one overrides the other, and we lose
some of the deps. If we update_data after each .oeclass load,
then DEPENDS_prepend affects DEPENDS immediately, but subsequently,
it applies against a DEPENDS variable which doesnt yet exist,
because the oeclass (in the case of base/INHERIT) is loaded prior
to defining DEPENDS in the .oe. The only solution I see is to
pick up _append/_prepend/_delete during the .oe feeder, and
append each of them to a list of tasks to do during the
update_data run. I.e. base sets DEPENDS_prepend to content/patcher,
then content/patcher ends up in the 'to prepend' list, and is then
prepended when update_data runs after the completion of the .oe
parse.
[x] Teach 'include' to fetch if necessary.
[x] Move this into handle() rather than include.
[ ] Alter 'export' handling, to support exporting a var without
defining the variable.
[ ] 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.
[x] Upstream source use:
* Build requirements
[x] Code will not be checked out into a temporary area
[x] Solve by leaving SRC_URI blank, and setting
S appropriately.
[ ] Code will not be automatically updated from CVS
[ ] Solve by making Fetch use md5.
[x] Follow dependencies
[x] Use oemake
[x] Default .oe argument for oebuild
[x] Default 'command' argument for oebuild
[x] Allow execution with a command, without .oe
[x] Allow execution with .oe, without command
[ ] Default .oe argument for oemake
[ ] Allow specifying a command on oemake execution
[ ] Must be able to execute 'oemake' within a subpackage
of an upstream package, and yet retain access to the
toplevel TMPDIR. Perhaps specify TMPDIR through
the environment.
[ ] Preferably also attempt to satisfy dependency,
which implies a way that the .oe files in
this repository are in OEFILES when built
from the subpackage build area.
[ ] Allow switching to a debug build for the entirety
of the build. Alter CONFIG for created .pro files,
and add -g to appropriate flags.
[ ] Nightly builds will use the same .oe files as those
used upstream. This is easily solved, since the use
of OE upstream already gives us the necessary event
handling.
[ ] Does not require that the build be done as root.
[ ] Simplicity of .oe file naming (PV/PR inside .oe)
[ ] Tests for versioning
[ ] Wrapper Makefile -> oemake
[ ] Command as <cmd> as opposed to do_<cmd>
[ ] Target device filesystem locations as metadata
items so that all the packages can install things
into proper locations. This is highly distribution
specific,
[ ] Real life test case: Opie
[x] default PN,PV,PR,CATEGORY in oe.conf
[x] Allow override of PN,PV,PR,CATEGORY within a .oe
[x] Allow filename to not contain PV, PR, CATEGORY
Needed because a .oe within an upstream source
will likely prefer to hold the version as an item
of metadata, rather than as the filename.
[x] Set TMPDIR to a path off of the original
TOPDIR, then set TOPDIR to the dir the .oe resides in,
in _all_ cases. This wont break functionality for most,
but will allow relative paths to behave properly, thereby
fixing this issue.
In this way we can sanely handle .oe files that
use relative paths extensively, such as those
using '.' as their 'S' variable.
[x] oebuild and oemake
[x] Teach the system to support grabbing OEFILES from upstream
using our fetch classes.
[ ] 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)
[ ] Default OEFILES based on .oe files in the current directory.
[.] oemake
[ ] Check for recursive dependency
[ ] Deal with multiple provides
[ ] Default OEFILES based on .oe files in the current directory.
[.] 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.
[ ] 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
[.] Image creation .oe files and/or external tool
[x] Rootfs population .oe
[.] image creation .oe files that depend on virtual/rootfs
[x] tarball
[ ] jffs2
[ ] cramfs
[ ] ext2
[ ] NOTE: need a way to ensure rootfs gets called only after the other
.oe's are built when it gets called via oemake, and need to ensure
image gets called only after rootfs. The latter is simple enough,
if the do_rootfs exists in the do_build digraph path. However, if
it exists in the digraph path, we cannot use the event handling means
of solving the former, we'd need to populate DEPENDS with every package
in OEFILES, other than itself and things that depend on it (recursion).
[ ] Once we have the per package deployment code, write a staging oeclass
that lets you use the FILES blocks for our deployment packages to do the
installs into the appropriate staging areas, to save time writing do_stage
functions.
[ ] 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.
[ ] Implement setvar, to give us the equivalent of 'staging' but for config
data.
[ ] Possibility: split staging by package, and maintain links based on
the base atom vs base+version, that sort of thing. Automatically add
proper include and lib paths to the flags variables based on the items
in DEPENDS. This 1) prevent unintentional include/link to the wrong
version of things, if multiple versions of things are floating around,
and 2) gives us a means of do_clean wiping out a given package's staging
items.
|
