Difference between revisions of "Architecture/To-Dos"
| Line 10: | Line 10: | ||
==Infrastructure Improvements== | ==Infrastructure Improvements== | ||
| − | [[BuildSpeedup | Speeding up the build system]], and maybe even make it consider global dependencies (currently, OOo has the notion of modules, which approximately map to toplevel directories in the build tree. Automatic build-time dependency calculation is currently only available on the intra-module level). | + | *[[BuildSpeedup | Speeding up the build system]], and maybe even make it consider global dependencies (currently, OOo has the notion of modules, which approximately map to toplevel directories in the build tree. Automatic build-time dependency calculation is currently only available on the intra-module level). |
| + | |||
| + | *Making the actual design more accessible, improving upon existing solutions like [http://ooo.ximian.com/lxr/ LXR] or [http://ooo.ximian.com/bonsai/ Bonsai]. Ultimately, this should result in refactorings of the source code being both much easier and much safer than today, by providing information where and how specific functionality is used. A prerequisite for that would be a parser that ''really'' knows about c++ - [http://www.gccxml.org/ gccxml] might be a starting point. | ||
Revision as of 21:10, 21 May 2006
This page intends to collect various architectural deficiencies (aka the pet peeves of various people) of OpenOffice.org, and lists the areas where's work in progress to improve on the architecture.
Depending on the specific count algorithm, OOo consists of approximately 7E6 lines of code (the overwhelming lot being c++, all other being an order of magnitude less (Java, Perl, Basic, Python)). This sheer size in and of itself is a problem - the code base is notorious for crashing or slowing down to a crawl various software engineering tools, from debugger to dependency analysis to reverse design extraction.
The code itself varies greatly in quality, style, and age (the latter invariably leading to the former, if you recall the history and evolvement of c++), with parts being there virtually unmodified for 10+ years, and others just recently written from scratch.
Taken together, this leads to a lot of complexity and redundancy, which is very hard to remove. What follows are some concrete instantiations of the aforementioned symptoms.
Infrastructure Improvements
- Speeding up the build system, and maybe even make it consider global dependencies (currently, OOo has the notion of modules, which approximately map to toplevel directories in the build tree. Automatic build-time dependency calculation is currently only available on the intra-module level).
- Making the actual design more accessible, improving upon existing solutions like LXR or Bonsai. Ultimately, this should result in refactorings of the source code being both much easier and much safer than today, by providing information where and how specific functionality is used. A prerequisite for that would be a parser that really knows about c++ - gccxml might be a starting point.
