[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] CDT Customer Feedback
|
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. /
