RE: [cdt-dev] CDT Customer Feedback

[Thomas Fletcher <ThomasF@xxxxxxx>]

Johan,

  Lots of significant changes have been made to the parser and associated
components which rely on its results.  As a result it works much more like
a compiler these days then it used to, including the ability to define as
part of the project preferences where external includes (ie system headers
live) as well as what defines are active.  I think that if you give the 
blessed CDT 1.2 release a whirl you will find that this particular issue
is greatly improved if not totally fixed.  

Thanks,
 Thomas

> -----Original Message-----
> From: Johan Walles [mailto:d92-jwa@xxxxxxxxxxx]
> Sent: Thursday, October 23, 2003 6:53 AM
> To: cdt-dev@xxxxxxxxxxx
> Subject: 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
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
>