Remove the necessity to append do_ to commands to clean up UI.
[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                 * Build requirements
33                         [x] Code will not be checked out into a temporary area
34                                 [x] Solve by leaving SRC_URI blank, and setting
35                                     S appropriately.
36                         [ ] Code will not be automatically updated from CVS
37                                 [ ] Solve by making Fetch use md5.
38                         [x] Follow dependencies
39                                 [x] Use oemake
40                         [x] Default .oe argument for oebuild
41                         [x] Default 'command' argument for oebuild
42                         [x] Allow execution with a command, without .oe
43                         [x] Allow execution with .oe, without command
44                         [x] Default .oe argument for oemake
45                         [x] Allow specifying a command on oemake execution
46                         [x] Must be able to execute 'oemake' within a subpackage
47                             of an upstream package, and yet retain access to the
48                             toplevel TMPDIR.  Perhaps specify TMPDIR through
49                             the environment.
50                                 [ ] Preferably also attempt to satisfy dependency,
51                                     which implies a way that the .oe files in
52                                     this repository are in OEFILES when built
53                                     from the subpackage build area.
54                         [ ] Allow switching to a debug build for the entirety
55                             of the build.  Alter CONFIG for created .pro files,
56                             and add -g to appropriate flags.
57                         [x] Nightly builds will use the same .oe files as those
58                             used upstream.  This is easily solved, since the use
59                             of OE upstream already gives us the necessary event
60                             handling.
61                         [x] Does not require that the build be done as root.
62                         [x] Simplicity of .oe file naming (PV/PR inside .oe)
63                         [ ] Tests for versioning
64                         [ ] Wrapper Makefile -> oemake
65                         [x] Command as <cmd> as opposed to do_<cmd>
66                         [ ] Target device filesystem locations as metadata
67                             items so that all the packages can install things
68                             into proper locations.  This is highly distribution
69                             specific, 
70                         [ ] Real life test case: Opie
71                 [x] default PN,PV,PR,CATEGORY in oe.conf
72                 [x] Allow override of PN,PV,PR,CATEGORY within a .oe
73                 [x] Allow filename to not contain PV, PR, CATEGORY
74                         Needed because a .oe within an upstream source
75                         will likely prefer to hold the version as an item
76                         of metadata, rather than as the filename.
77                 [x] Set TMPDIR to a path off of the original
78                     TOPDIR, then set TOPDIR to the dir the .oe resides in,
79                     in _all_ cases.  This wont break functionality for most,
80                     but will allow relative paths to behave properly, thereby
81                     fixing this issue.
82                         In this way we can sanely handle .oe files that
83                         use relative paths extensively, such as those
84                         using '.' as their 'S' variable.
85
86 [x] oebuild and oemake
87         [x] Teach the system to support grabbing OEFILES from upstream
88             using our fetch classes.
89
90 [ ] oebuild
91         [ ] Implement and test check_md5, taking nostamp into account.
92         [ ] Add '--undo'/'-u' cmdline opt that calls the 'undo' task
93             for the supplied task.
94         [ ] Add '--rebuild'/'-r' cmdline opt that calls the 'undo' task
95             for the entire upward path in the digraph, then builds that task.
96             (same thing done when the md5 changes on an affected var in
97              check_md5)
98         [x] Default OEFILES based on .oe files in the current directory.
99
100 [.] oemake
101         [ ] Check for recursive dependency
102         [ ] Deal with multiple provides
103         [x] Default OEFILES based on .oe files in the current directory.
104
105 [.] oemaked
106         [ ] Monitor the stamps for a given .oe file as well, to ensure
107             changes in build state as well as changes to build metadata result
108             in a rebuild.
109
110 [ ] packages
111         [ ] add cross binutils and binutils
112         [ ] add gcc
113         [ ] figure out where to put the glibc install into the toolchain dir,
114             which is only needed by gcc pass 2.
115         [ ] add qtopia 1.6.1
116         [.] add qt 2.3.6
117         [ ] convert packages from OpenZaurus buildroot
118
119 [.] Image creation .oe files and/or external tool
120         [x] Rootfs population .oe
121         [.] image creation .oe files that depend on virtual/rootfs
122                 [x] tarball
123                 [ ] jffs2
124                 [ ] cramfs
125                 [ ] ext2
126         [ ] NOTE: need a way to ensure rootfs gets called only after the other
127             .oe's are built when it gets called via oemake, and need to ensure
128             image gets called only after rootfs.  The latter is simple enough,
129             if the do_rootfs exists in the do_build digraph path.  However, if
130             it exists in the digraph path, we cannot use the event handling means
131             of solving the former, we'd need to populate DEPENDS with every package
132             in OEFILES, other than itself and things that depend on it (recursion).
133
134 [ ] Once we have the per package deployment code, write a staging oeclass
135     that lets you use the FILES blocks for our deployment packages to do the
136     installs into the appropriate staging areas, to save time writing do_stage
137     functions.
138 [ ] Write helper functions ala ebuild's dobin/dodoc/etc and debian's dh_*.
139         [ ] Note, if we do this using actual commands within the .oe file
140             as opposed to shell helpers, the buildsystem is then aware
141             of what files are libs, what are includes, etc, and we could
142             then do a sane automatic population of staging based on that
143             information. 
144 [ ] Implement setvar, to give us the equivalent of 'staging' but for config
145     data.
146 [ ] Possibility: split staging by package, and maintain links based on
147     the base atom vs base+version, that sort of thing.  Automatically add
148     proper include and lib paths to the flags variables based on the items
149     in DEPENDS.  This 1) prevent unintentional include/link to the wrong
150     version of things, if multiple versions of things are floating around,
151     and 2) gives us a means of do_clean wiping out a given package's staging
152     items.