Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] C-like Language Support

I think that's why this is interesting. I'm not sure we've been able to successfully use the existing extension points to do things like this, the core.language one in particular. They just aren't set up to properly look at parts of files.

Using the ErrorParser is an interesting approach. I have a feeling that would slow things down significantly and you don't get useful information about the embedded code, assuming you want that. But for cleaning up the errors, that might be the best way.

Doug.


From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of George Loring [George.Loring@xxxxxxxxxxx]
Sent: Thursday, March 27, 2014 9:47 AM
To: 'cdt-dev@xxxxxxxxxxx'
Cc: Alan Riedel
Subject: Re: [cdt-dev] C-like Language Support

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

 

 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of George Loring
Sent: Tuesday, March 25, 2014 5:40 PM
To: 'cdt-dev@xxxxxxxxxxx'
Cc: Alan Riedel
Subject: [cdt-dev] C-like Language Support

 

Hello,

 

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.

 

Thanks,

 

George Loring Technical Expert
Enablement Services

Open Source Team

 


Back to the top