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.