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?
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Marc Khouzam
Sent: Wednesday, March 26, 2014 10:29 AM
To: 'cdt-dev@xxxxxxxxxxx'
Cc: Alan Riedel
Subject: Re: [cdt-dev] C-like Language Support
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