Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] CDT Customer Feedback
I'd like to chime in with some feedback of my own. I'm working on JRockit ("http://dev2dev.bea.com/products/wljrockit81/index.jsp";) and have been trying to use previous versions of the CDT. JRockit consists of about 260k lines of C code.
The problem that is blocking me from using CDT with the JRockit source code is that #include files and preprocessor macros aren't handled correctly ("https://bugs.eclipse.org/bugs/show_bug.cgi?id=36770";). I made my last attempt at using the CDT somewhere in April, but the bug is still open (with a target milestone of 2.0), so I assume this is an issue that will be fixed for 2.0.
As we pass -D flags to the C compiler(s) in the Makefile, we also need a way to tell the indexer about the macros #defined outside of the source code. This together with 36770 would cover correct parsing of the sources.
The one remaining step (that I know of...) for the indexing functions to work well with our source code is to be able to tell what source files should be ignored. We have a naming convention of suffixing platform-dependent files with _win32, _linux, _linux64 and such depending on what platform they are for. Also, some code is in directories named "windows" and such. If I'm developing for ia64 I don't want the indexer to find ia32 implementations of different functions for me.
The -D flags and the file suffixes / directory names are covered by "https://bugs.eclipse.org/bugs/show_bug.cgi?id=25682";, which hasn't received any target milestone. 

  Cheers //Johan

Thomas Fletcher wrote:

In the monthly calls, I've often made a comment about sharing the customer
feedback information which some of the commercial "CDT re-sellers" are receiving. Since we are starting to put together the 2.0 plan, I thought 
that it would be a good time for me to provide some of the common feedback
that we get from customers during their "early days" (ie within the first
few days of working with the tools before they find work-arounds and start
to go silent about problems that they are encountering).

The list is rather long, but I've shortened it to stuff which I feel is
most relevant to CDT (as opposed to Eclipse and/or QNX) and here is what
I ended up with:

---

Overall comments: Project organization and ease of source manipulation
has a _huge_ _huge_ impact on the adoption of these tools

- Importing source and building/organizing projects is non-trivial
and non-obvious. There are many difficulties in dealing with custom project structures. 

- Lack of control over build and ability to customize.
  Specifically:
  - Custom mix of debug and non-debug per component (ie file)
  - Ability to rebuild (not link) just a single file to check
    for errors.
  - Support for both binary and source dependancies and building
and linking only what is required. 
- Build is too slow in the IDE compared to the commnd line.  The
  output parsing and console windows seem to cause an enormous
  penalty.  Suggestion is to push results to a temporary file on
  disk and process it seperately rather than "in-line".

- Binding of keys/buttons for build commands, including custom
  commands.  In general key binding is a touchy issue =;-)

- Don't want to have to do additional Makefile manipulation
  by editing files (want preferences to cover everything).
- Memory and performance overhead for large projects (100,000+ files) is unacceptable. "More caching and less working" I 
  believe were one customers direct words.
- Want a simple, single click mechanism to build and debug applications. 

- Lack of source nagivation and cross referencing tools.
  Specifically:
  - C++ Class browsing functionality
  - Opening of C++ types (typed in)
  - Opening of C functions (typed in)
  - Jumping from variables to declarations (cursor in source)
  - Jumping to function definitions (cursor in source)
  - Toggling from source to header definitions
- Lack of coherent and consistant code completion. 
  Specifically:
  - Missing completions from local project or included files
- Local variable completion - Structure and Class member completion 
  - Pre-processor completion (ie #define, #include ...)

- Integrated documentation support to enhance code completion
  (format agnostic, but Javadoc/Doxygen styles have been requested)
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top