continue merging the verbose/debug behaviour into the global report file
continue moving classes into DEPS namespace as the API stabilizes
finalize filename portability support, using File::Spec volume information (or, possibly better but using non-core module, using Path::Class)
allow to associate attributes to files (eg. an ARCH attribute for multi-architecture trees, like kernels, development tools and emulators)
modularization (finish the restructuring into a cleaner and more modular design)
allow passing options to modules (-O param=value ?)
allow to define several views in a project, several of which can be generated by default.
find out whether we can declare protocols/pure-virtual-classes in some way, to cleanup the class graph
generalize --prefix-strip
give consistent access to all commonly-needed features through command-line and class customization
Maybe allow to use as nodes other objects than files (eg. URI objects ?), for ultimate generalization.
Provide a mechanism for any transform to record informations for the report file.
Allow to plug verifiers (probes ?) in a clean way (eg. verify the transitive reduction, or any consistency check)
allow to run from a build directory
--class does not allow to find the project file (need to set PERL5LIB)
caller must prepend path to source tree to --prefixstrip and all relative -I flags
find the accessory classes as easily as possible (like bugzilla ?)
better robustness to incorrect arguments (eg. --consolidate 1:2)
automate --help production (see Pod::Usage ?)
multi-sheet paper support may be broken
use an existing source of paper formats (libpaper, LC_PAPER, whatever)
maybe use graphviz' tred(1) to check our transitive reductions, and/or as alternative transform plugin.
autodetection of the language to use based on filenames
provide an initial list of system directories to avoid repeating them (ask compiler)
allow -I syntax for programs using eg. -I. from source subdirectory
write other extractors (java, python, …)
C-like extractor
some support for CPP symbol conditionals (mostly #ifdef), perhaps coupling this with attributes
write an openc++-based dependency extractor
extract more fine-grained dependency (depending on a header does not necessarily imply depending on code)
handle (warn about) the case where the declarations for a given implementation file are scattered in more than one header
detect undeclared dependencies (eg. manually inserted prototypes)
check necessity of declared includes
perl extractor
remove arbitrary limitations
report use/require lines we could not completely parse
do some invariant analysis when importing a module using a variable name. Investigate drawing 1->n links in this case.
proper way to define include paths in project class
make default project-class consider multiple levels of directories as group levels, but only if they (consistently ?) have multiple subgroups ?
write a linux-kernel class and others as examples :)
provide a simple hash-based filelabel implementation
Abstract the grouping process into GroupHierarchy objects
Provide a generic regexp-based grouper
provide tools for automatic grouping (eg. using cycles, or selected external deps, or from leaves)
keep group members as close as possible
(style) give more weight to intra-group edges
Improve transitive reductions implying multiple edges into a single cycle, to prefer an edge into the lowest-level common group
specify restrictions on allowed deps at a given grouping level, and show violations in red.
allow styling through font color, node shape (dot/tulip), number of peripheries (dot)
allow to draw non-consecutive group levels (eg. --consolidate 1,3) (tool issue to be resolved by deps-grapher)
allow different node shapes when mixing high-level nodes with lower-level ones through the default singleton groups (Node::PerGraph style, similar to PerGroup)
optionally show labels (using attributes ?) for node ingredients and color edges according to them
optionally show external deps (deps on files not on command-line)
limit graph to one or more given group(s) of files (specified by <level>:<label>)
draw cycles in a given color
draw a specific path
provide automatic coloring schemes
color intra-group edges with the same color as nodes (post-processing ?)
allow to request drawing of who in a high-level node points to another node (ie. violates some constraint)
propagate excuses in some way when they are dropped by the transitive reducer
investigate candidate tools for hyperbolic layout ?
allow to show the count of deps in a given edge using line width instead of labels
write more documentation
write a testsuite.
ensure that all provided non-abstract classes are self-contained
The standard GUI should be able to navigate the project definition, visualizing the hierarchy of groups, (un)folding groups and edges, displaying single culprits from a group, and anything you can think of.
For an engine, maybe with graphviz' lefty, or write a specialized tulip gui ? A self-customizable GUI like entity may be a good idea. Since entity has support for OpenGL areas, maybe it can be made to embed tulip graphs.