RE: [cdt-dev] CDT Customer Feedback

[John Camelon <jcamelon@xxxxxxxxxx>]

That defect is still open, since CModel uses QUICK_PARSE and thus does not 
follow inclusions or maintain a symbol table. 
However, you can supply build information to the parser through the 
properties on a managed or standard make project for
Search and Code Assist features (which use COMPLETE_PARSE). 

JohnC

cdt-dev-admin@xxxxxxxxxxx wrote on 10/26/2003 03:59:06 PM:

> So what more needs to be fixed before 36770 "Incorrect preprocessor
> branch taken" can be closed?
> 
>   Cheers //Johan
> 
> lör 2003-10-25 klockan 14.48 skrev Thomas Fletcher:
> > 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
> > > 
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/cdt-dev
> -- 
> Johan Walles                     WWW:
> http://www.student.nada.kth.se/~d92-jwa
> Vultejusvägen 40                 Hem:  08-371657      /   Great minds
> run   |
> 168 56 BROMMA                    GSM: 070-7106277     |  in great
> circles.  /
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev