From 3c2969870da874f572adc59b11d22ee6a5e34c05 Mon Sep 17 00:00:00 2001 From: Chris Larson Date: Thu, 1 Jul 2004 23:29:02 +0000 Subject: Delete: doc/TODO --- doc/TODO | 128 --------------------------------------------------------------- 1 file changed, 128 deletions(-) delete mode 100644 doc/TODO diff --git a/doc/TODO b/doc/TODO deleted file mode 100644 index 2717a9761..000000000 --- a/doc/TODO +++ /dev/null @@ -1,128 +0,0 @@ -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. - [ ] Parsing - [ ] Support $${VAR} or \${VAR} for something we want passed to the shell - without being interpreted as an OE variable. - [ ] 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 - [ ] 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. - [ ] Fetch - [ ] 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. - [ ] Data - [ ] 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 - [ ] Completely revamp packaging classes. Swallow stdout & stderr of - tool used, output our own status, and include HOST_ARCH in tarfn. - -[ ] 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) - [ ] Add '--short-circuit'/'-s' cmdline opt that skips task dependencies - and calls the specified task directly. - -[.] 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. - -[.] oeinstall - [.] types - [x] direct - [ ] {pre,post}{inst,rm} - [ ] tarball - [ ] rpm - [ ] deb - [ ] ipkg -[.] oeimage - [.] types - [x] jffs2 - [ ] ext2 - [ ] cramfs - [ ] tarball - -[.] packages - [.] transition packages from OpenZaurus buildroot - [ ] all packages need deviceisms added - [ ] all packages need output packaging dealt with properly, and - packaging granularity increased. - [ ] modutils - [ ] /etc/modules & /etc/modules.conf - -[ ] 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 - - [ ] Data structure(s) for metadata and metadata store - [ ] .oe parser - [ ] manual - [ ] lex/yacc (flex/bison) - [ ] Code execution, status and event handling - [ ] Build - '----Package - '----Task - [ ] Fetching things from upstream - [ ] Possibly utilize apt-get "methods" - [ ] CVS method - [ ] BK method - [ ] SVN method - [ ] Autobuild daemon - [ ] XML/RPC control and metadata exchange interfaces -- cgit 1.2.3-korg