Ah, OK. I think we used extension
points to add custom ErrorParsers for our different
Unix OS’s (org.eclipse.cdt.core.ErrorParser).
Actually, I see org.eclipse.cdt.core.language which
according to the documentation has supplied
implementations for gcc and g++. Is this what you
mean? We’d add a new implementation for our
embedded SQL language? Or is the thought to have a
different extension point for specific statements in
otherwise basic C code?
Hi George,
I definitely remember interest in
what you were doing from other people at the
presentation.
One of the ideas was to add
extension-points to CDT so that particular
statements that are not
handled properly could be dealt with
based on the extension code. This is not my area of
expertise
but I hope others can join in.
Also, I believe the discussion on
Synchronized Projects from PTP could be interesting
to you:
http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg27302.html
It would help address the fact that
you build on a different machine than where you
code.
PayPal had a similar issue and so
does the Yocto project.
I hope we can work together to
improve CDT.
Marc
My name is
George Loring. I’m a Technical Expert for
Walmart and gave a presentation last week at
EclipseCon concerning some plugins and patches
we wrote for Eclipse & CDT to help make it
work for our environment. One item of
particular interest was a patch we wrote to get
CDT to ignore embedded SQL statements that are
within our C code. In Walmart code modules with
certain extensions are ran through a
pre-processor that turns these embedded SQL
statements into function calls. Our patch dealt
with the portion of CDT that deals with static
code analysis and syntax highlighting. For our
particular situation there is also a special
type of include directive that we had to code
for. We added the syntax for this special
include directive to cause CDT to pull in the
special header file and parse any function
prototypes, macro definitions, etc.
There were
others in the presentation who apparently have
similar types of situations at companies they
have worked for. I believe there may be some
interest in implementing this in a slightly
different way to allow for a user to configure
certain types of statements (maybe based on what
the statement begins and ends with) so that it
can be essentially ignored by CDT. Maybe the
user could also configure additional include
directives. Part of this configuration could
also allow them to set in what color the ignored
statements should be displayed.
Another approach
may be a way to allow a user to configure
additional statements that are valid syntax.
So, rather than ignoring the statements as our
patch does it could just be told of these
additional key words, how they should be treated
(what type of token) and what combination of
statements were valid. I realize this is likely
a bigger endeavor and maybe should be approached
in a manner where a developer could install an
additional language “pack” (in other words, not
something they could configure themselves), but
seems less like a hack than our initial approach
of just ignoring the statements completely.
Marc talked with
me after my presentation and asked that I email
this group to see how we might proceed. We are
eager to take any advice from the group so that
we might look at getting this in the core build
for CDT. Eclipse & CDT are fantastic tools
for our C developers. They really have made us
much more productive and quite honestly made
coding in C much more enjoyable. We’d like the
opportunity to help make Eclipse & CDT
useful for other developers that may have
similar situations as ours.
George Loring
Technical Expert
Enablement Services
