CDT R1.0 Release - Friday Mar 29, 2002

This document is intended to point out what's new since CDT R0.5 as 
well as known issues with the R1.0 Release.  These issues will be 
addressed in future releases.  

HIGHLIGHTS OF WHAT'S NEW SINCE CDT R0.5
---------------------------------------

DEBUGGER
 - Debugger now able to locate DLL source
 - Editing the content of a Storage Monitor supported
 - Fixes to the operation of the GDB Console
 - Halting a multi-threaded application supported 
 - Monitoring of template variables supported.
 - Updated Debugger Help

VIEWS\UI
 - New Declarations Browser (support for drilling down in C/C++ Object Views)
 - Multiple Selection support for actions in C/C++ Projects view
 - Enhanced command integration with C/C++ Projects view
 - Output View enhancements (Shell & Standard Input Support Added)
 - General View enhancements (improved view selection, performance, view 
   enabling\disabling)
 - New icons

REMOTE PROJECTS
 - Detection & Cleanup on severed remote connection
 - UTF-8 data communication layer
 - Performance improvements in file transfer and project replication
 - Support for remote command specifications

AUTOCONF SUPPORT
 - Streamlined Autoconf workflow
 - Addition of Autoconf preference page.

C/C++ PARSER 
 - Significant fixes to problems that prevented some /usr/include headers
   from being parsed properly.
 - Ability to Cancel Parse Jobs
 - Various performance improvements

HELP SYSTEM
- Updated User Documentation
- Filtering Support for System Help Search.
- Topic Indexing for HTML System Help



KNOWN ISSUES WITH CDT R1.0
--------------------------

This list is not complete, please refer to the CDT Bugzilla database 
at http://bugs.eclipse.org for a comprehensive and up-to-date list of 
known bugs.


Project Issues (Local and Remote)
---------------------------------

1.  Some memory issues have been reported when working with large projects.
2.  There are some timing issues with some asynchronous actions that can result 
    in the UI not realizing that the action is finished.  One symptom of this is
    a Progress Bar that keeps working. 
3.  Markers (Breakpoints, Bookmarks, Error Results etc) have minimal support 
    when working with Remote Projects.  They are not persisted, and are not  
    visible in the typical Eclipse views (Task List, Search Results).


Parsing Issues
--------------

The parser has been written to handle both C and C++ and is really a work
in progress.  There are constructs or features of both languages that the
parser does not currently handle gracefully or at all. When the parser
encounters some code that it can't handle, it tries to skip over the
problem and continue parsing.  When it does this, it creates Parse 
Exception objects that will appear intermingled in with the other C/C++ 
objects when looking at the Details view of a Parsed File...
Here are some of the most common known problems:

- There are several known issues with UI responsiveness during a large parse job.  
  For now, once a large parse has been started, it is best to wait until the status
  bar has disappeared before trying to access the parse information in the UI.
  The status bar actually disappears when a "first-level" parse of all files has
  been completed.  There is still more work being done by the parser at this point.
  For some very large parse jobs, UI responsiveness may not return to normal until 
  the parser is completely finished.  Currently the only way to know when the 
  parser is completely finished is to check the CPU usage for the java vm used
  to start eclipse, and verify that it is near 0.   The performance of the parser
  is is one of the key areas that will be addressed in future releases of the CDT.
 
- When parsing a large project, there is a potential to use a large amount 
  of memory. If you encounter memory problems create a batch\script 
  file that starts eclipse (so that we can have control over the command-line 
  parameters sent to the JVM.  A typical script would look like this:

  java -Xms100m -Xmx200m -verify -cp startup.jar org.eclipse.core.launcher.Main  
  
  The -Xms and -Xmx set the minimum and maximum memory size that the JVM is invoked with.
  (We will be looking into memory issues in upcoming releases)

- Persistence of Parse Information for large remote projects has been known to not work,
  and might actually cause other problems.
 
- Known language limitations:
    - Some variable\function\struct names are not shown correctly.  Some of the more 
      common problems include Operator Overloading, and C++ Nested Name Specifications (A::B::C)
    - Some macro replacements will not behave correctly
    - Expression Evaluation is currently turned off in the preprocessor, so #if, #ifdef etc,
      will not actually conditionally include source.  Since we don't yet provide a way for a 
      user to set macro values we felt that it was a better idea to parse all source.
      Depending on how your source is structured, this can cause duplicate objects or affect the 
      accuracy of parse information. 
    - If a function is forward declared, both the definition and declaration
      will appear as separate objects
    - Some casts are not parsing properly  
    - C++ Parsing is has not been well exercised so there are likely problems with templates,
      namespaces, etc.


Command Launcher View
--------------------

1. The Command Launcher View requires an object in the C/C++ Projects view to be selected.
   If you find that the Run Button in the Command View doesn't appear to work, 
   goto the C/C++ Projects view and select a Project or File and try again.


Command Specifications View
---------------------------

1. Users may need to click on the project to set the focus in the navigator
   before adding/removing command specifications within that project scope
2. When creating a command specification using the wizard, the selected project will be
   highlighted and selected automatically. Changing it to another project
   from within the wizard will not cause the command specification to belong to the
   selected project. 


Searching
---------

1. Search results only appear for objects contained in the files of local projects.
   Objects contained in included files or remote projects do not show up in the 
   search results view. For remote projects use the Output view to see the results.


General View Issues
-------------------

1. For large projects, refreshing or refiltering Parse Views can be quite slow.
2. The C/C++ Projects view and the Navigator are not always in sync. The solution is to
   do a refresh in the view that appears not up to date.


Debugger issues
---------------

1. When terminating a debug session, please avoid terminating the debug daemon.
   If the debug daemon is terminated, you will have difficulties starting another 
   debug session with the daemon listening to the same port.  You will get this 
   error message:
      "Failed to launch the PICL UI Daemon, the port may be busy.  
       Try changing the port in the PICL Debug preference page."
   To get around this problem, you can either restart Eclipe, or change the 
   Debug Daemon port. To change the port that the debug daemon listens to, 
   go to Windows->Preferences->Debug->Compiled Debug.
2. Some views in the Debug Perspective may not be updated properly after a command
   has been executed from the GDB Console.

For debugger features that are being considered for future releases, 
please see todo.txt.


Project Management Issues (autoconf and automake)
-------------------------------------------------

1. In order to make your executable debuggable, you need to edit the Makefile.am
   and insert one of the following lines:
     CXXFLAGS=-g
     or
     CFLAGS=-g
2. If your project contains source files in its top level directory, then use the 
   "Create Programs Makefile.am" action under the "Advanced..." autoconf menu prior
   to running "Configure".