Update TODO
[bitbake.git] / doc / TODO
1 TODO:
2
3 [x] oe package
4         [ ] Remove duplicated implementations, and convert everyone to the new
5             data and parse methods.
6         [ ] API Sanity Audit.
7         [ ] Comment/Docs Audit.
8         [.] Implement API testing using doctest.
9         [x] BUG: If we only run an update_data after a load of an .oe,
10             but not for a .oeclass, if multiple .oeclasses define, say, for
11             example DEPENDS_prepend, one overrides the other, and we lose
12             some of the deps.  If we update_data after each .oeclass load,
13             then DEPENDS_prepend affects DEPENDS immediately, but subsequently,
14             it applies against a DEPENDS variable which doesnt yet exist,
15             because the oeclass (in the case of base/INHERIT) is loaded prior
16             to defining DEPENDS in the .oe.  The only solution I see is to
17             pick up _append/_prepend/_delete during the .oe feeder, and
18             append each of them to a list of tasks to do during the
19             update_data run.  I.e. base sets DEPENDS_prepend to content/patcher,
20             then content/patcher ends up in the 'to prepend' list, and is then
21             prepended when update_data runs after the completion of the .oe
22             parse.
23         [x] Teach 'include' to fetch if necessary.
24             [x] Move this into handle() rather than include.
25         [ ] Alter 'export' handling, to support exporting a var without
26             defining the variable.
27         [ ] Add support for 'anonymous' OE functions in .oe{,class} files.
28             These functions are to be executed immediately at parse time,
29             thereby giving one the ability to exert more control over the set
30             of variables.
31         [x] Upstream source use:
32                 [ ] Split oemake's knowledge of AVAILABLE OEFILES from its
33                     knowledge of which packages are to be built.
34
35                 * Build requirements
36                         [x] Code will not be checked out into a temporary area
37                                 [x] Solve by leaving SRC_URI blank, and setting
38                                     S appropriately.
39                         [ ] Code will not be automatically updated from CVS
40                                 [ ] Solve by making Fetch use md5.
41                         [x] Follow dependencies
42                                 [x] Use oemake
43                         [x] Default .oe argument for oebuild
44                         [x] Default 'command' argument for oebuild
45                         [x] Allow execution with a command, without .oe
46                         [x] Allow execution with .oe, without command
47                         [x] Default .oe argument for oemake
48                         [x] Allow specifying a command on oemake execution
49                         [x] Must be able to execute 'oemake' within a subpackage
50                             of an upstream package, and yet retain access to the
51                             toplevel TMPDIR.  Perhaps specify TMPDIR through
52                             the environment.
53                                 [ ] Preferably also attempt to satisfy dependency,
54                                     which implies a way that the .oe files in
55                                     this repository are in OEFILES when built
56                                     from the subpackage build area.
57                         [ ] Allow switching to a debug build for the entirety
58                             of the build.  Alter CONFIG for created .pro files,
59                             and add -g to appropriate flags.
60                         [x] Nightly builds will use the same .oe files as those
61                             used upstream.  This is easily solved, since the use
62                             of OE upstream already gives us the necessary event
63                             handling.
64                         [x] Does not require that the build be done as root.
65                         [x] Simplicity of .oe file naming (PV/PR inside .oe)
66                         [ ] Tests for versioning
67                         [ ] Wrapper Makefile -> oemake
68                         [x] Command as <cmd> as opposed to do_<cmd>
69                         [ ] Target device filesystem locations as metadata
70                             items so that all the packages can install things
71                             into proper locations.  This is highly distribution
72                             specific, 
73                         [ ] Real life test case: Opie
74                 [x] default PN,PV,PR,CATEGORY in oe.conf
75                 [x] Allow override of PN,PV,PR,CATEGORY within a .oe
76                 [x] Allow filename to not contain PV, PR, CATEGORY
77                         Needed because a .oe within an upstream source
78                         will likely prefer to hold the version as an item
79                         of metadata, rather than as the filename.
80                 [x] Set TMPDIR to a path off of the original
81                     TOPDIR, then set TOPDIR to the dir the .oe resides in,
82                     in _all_ cases.  This wont break functionality for most,
83                     but will allow relative paths to behave properly, thereby
84                     fixing this issue.
85                         In this way we can sanely handle .oe files that
86                         use relative paths extensively, such as those
87                         using '.' as their 'S' variable.
88
89 [ ] oebuild
90         [ ] Implement and test check_md5, taking nostamp into account.
91         [ ] Add '--undo'/'-u' cmdline opt that calls the 'undo' task
92             for the supplied task.
93         [ ] Add '--rebuild'/'-r' cmdline opt that calls the 'undo' task
94             for the entire upward path in the digraph, then builds that task.
95             (same thing done when the md5 changes on an affected var in
96              check_md5)
97
98 [.] oemake
99         [ ] Check for recursive dependency
100         [ ] Deal with multiple provides
101
102 [.] oemaked
103         [ ] Monitor the stamps for a given .oe file as well, to ensure
104             changes in build state as well as changes to build metadata result
105             in a rebuild.
106
107 [ ] packages
108         [ ] add cross binutils and binutils
109         [ ] add gcc
110         [ ] figure out where to put the glibc install into the toolchain dir,
111             which is only needed by gcc pass 2.
112         [ ] add qtopia 1.6.1
113         [.] add qt 2.3.6
114         [ ] convert packages from OpenZaurus buildroot
115
116 [.] Image creation .oe files and/or external tool
117         [x] Rootfs population .oe
118         [.] image creation .oe files that depend on virtual/rootfs
119                 [x] tarball
120                 [ ] jffs2
121                 [ ] cramfs
122                 [ ] ext2
123         [ ] NOTE: need a way to ensure rootfs gets called only after the other
124             .oe's are built when it gets called via oemake, and need to ensure
125             image gets called only after rootfs.  The latter is simple enough,
126             if the do_rootfs exists in the do_build digraph path.  However, if
127             it exists in the digraph path, we cannot use the event handling means
128             of solving the former, we'd need to populate DEPENDS with every package
129             in OEFILES, other than itself and things that depend on it (recursion).
130
131 [ ] Once we have the per package deployment code, write a staging oeclass
132     that lets you use the FILES blocks for our deployment packages to do the
133     installs into the appropriate staging areas, to save time writing do_stage
134     functions.
135 [ ] Write helper functions ala ebuild's dobin/dodoc/etc and debian's dh_*.
136         [ ] Note, if we do this using actual commands within the .oe file
137             as opposed to shell helpers, the buildsystem is then aware
138             of what files are libs, what are includes, etc, and we could
139             then do a sane automatic population of staging based on that
140             information. 
141 [ ] Implement setvar, to give us the equivalent of 'staging' but for config
142     data.
143 [ ] Possibility: split staging by package, and maintain links based on
144     the base atom vs base+version, that sort of thing.  Automatically add
145     proper include and lib paths to the flags variables based on the items
146     in DEPENDS.  This 1) prevent unintentional include/link to the wrong
147     version of things, if multiple versions of things are floating around,
148     and 2) gives us a means of do_clean wiping out a given package's staging
149     items.