[cdt-dev] CDT project update

[Sebastien Marineau <sebastien@xxxxxxx>]

Hi all,

just want to give a quick update on the CDT project.

Here's a summary in point form of where we stand:


** Overall project **

- The project focus in the last month has been twofold: completing the
intial project "infrastructure", as well as doing the CDT debugger
re-architecting. As a result, other areas (plans, testing, builds) have
not progressed as quickly.

- The web site has been mostly updated with base information on the CDT
project, as well as some user and developer information. We still need
help in this area.

- Currently, the CDT is comprised of 6 main components, as outlined in July.
A couple of supporting components have been added as well; these include
the feature plugins, as well as junit test plugins. A proposal to add
platform-specific fragments will go up shortly.

- We've not posted the official plans up yet. Drafts should be circulated on
the mailing lists in the next few days, with posting by end of week. 

- Preliminary builds of the CDT have been posted. The latest includes the 
debugger and launcher components. The intention is to get to automated daily
builds (if you have not tried it, go to
http://www.eclipse.org/tools/index.html
and follow the links to C/C++ downloads).

- At this point, with the progress made on the debugger, we feel we are
still
on track for an October "prototype" version. Risks and outstanding items 
are outlined below.


** CDT Core plugins **

- The main work in this area has been on Eclipse 2.0 catchup items, fixing
compile
warnings as well as add in the persistent CDT project property store.
- Remaining items for October include:
  - address scalability of indexer
  - review of C model APIs and parser
  - preliminary version of build model
- unless we get additional resources in the next week, it is unlikely
that any work on a C++ class browser will get done.


** Debugger and launcher **

- The first prototype version of the CDI was posted on the CDT mailing list.
Good
feedback was received and adjustments were made. After completing the the
reference
gdb/mi plugin (see next item), it is likely that some changes will have to
be done
to the CDI.

- A lot of work has gone into the gdb/mi backend. Due to the differences
between
gdb 5.0 and 5.2, the mi parser was completely re-written (QNX's Momentics
debugger
was designed to work with gdb 5.0). As it stands, we now have a preliminary
version
of the CDT debugger that can debug on both QNX, Linux and Solaris hosts
(with caveats).

- The debugger UI components are progressing well.

- Due to the volume of code being written and/or re-architected and the time
pressure, the developers have not been posting their changes to the patch 
mailing list; rather, the code has been going directly into Eclipse's CVS.
We will
start posting "checkin" diffs to the mailing list shortly.

- An initial extensible launcher framework has been commited. This allows
one to 
extend the launcher to have OS or target-specific launch options (e.g.
launch
gdb with different options or launch gdb from a different path).

- There are some mi issues with gdb on Linux self-hosted that will gate
the self-hosted Linux CDT. QNX to discuss with Redhat how to best
resolve these for october.

** Testing **

- Initial JUnit components have been created. They are named
org.eclipse.cdt.ui.tests (tests for cdt.core and cdt.ui) and 
org.eclipse.cdt.debug.ui.tests (debugger and launcher testcases).
A couple of tests have been commited but test coverage is almost
non-existent. This is another good area for folks to help out.


** Short-term action items and where we need your help **

- Post, review and approve the plans. This is an action item that I have for
the week.

- Currently, we're producing a single build for all host platforms. This
will
change shortly as we add host-specific fragment plugins to the CDT, and
would
be a good time to address host-specific packages (e.g. RPMs).

- We need further discussions on testing strategy. There's now a pretty
large body
of code that has little or no formal test coverage. Building up a Junit test
suite
for this codebase can be a lot of work, so we'll need to prioritize what to
test
(e.g. at a minimum all public API's) as well as get some help for the test
development.

- There are other areas where we need help. In particular, documentation is
currently
rather weak. While I believe we will do pretty well with "developer"
documentation, we
need to assign some resources to user documentation.


Cheers,

Sebastien