Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Correct way to fork CDT Plugin

Hi everyone,

I follow this mailing list for a while now, but I usually ask my stupid questions about CDT on StackOverflow where always the same people give me helpful answers and even upvote my question, no matter how stupid it is. This time I was suggested to ask in this mailing list, and I hope I don't bother you. I would be grateful If someone can give me helpful answers on what I ask in the short part. In case the short part is too short to understand the question, I added a longer explanation.

In short:
What is the best way to fork org.eclipse.cdt.core? I need to evaluate for our company whether forking cdt is a good option for us or not. Are there best practices? I want to fork as little as possible, because I only need to change few functionalities, mainly in Indexer and Source Parser classes. I also need to avoid conflicts with the original CDT plugins so that our plugin works alongside the CDT plugins. Is that possible without forking everything

I did:
git clone http://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git
Then I created a new branch "fork" based on master and replaced every string "org.eclipse.cdt.<>" by "my.url.cdt.<>". I renamed the import statements, the dependencies, the directory names and every occurence of "org.eclipse.cdt". Then I imported started to import "my.url.cdt.core" in eclipse and then "ui" and "native", because I noticed that I need to add at least these two.


Long explanation on why I want to evaluate if forking CDT is a good choice:
We are working on a new User Interface for our tool "RT-Tester". The new UI is an Eclipse Plugin. RT-Tester is a test automation tool for automatic test generation, test execution and real-time test evaluation. It comes with a powerful test language (Real-Time Test Language, RTTL) for efficient development of procedures for automated test execution. That language is based on C++ and adds some new concepts. When coding in RTTL our Eclipse Plugin should provide the coder with a working SourceParser and Indexer. Until now I tried to do achieve that the 'normal' way: by using extension points to add languages and content types and extending CDT classes. But I couldn't find good work arounds for some problems (that's why I was asking so many questions on SO). Examples for bad work arounds: Building the Abstract Syntax Tree becomes a problem when it comes to new concepts that are not part of C++. For example there is a concept called "abstract machine" which looks something like this:

@abstract machine {

}

Some of the other RT-Tester-concepts are only allowed to be used inside an abstract machine body and others are only allowed to be used outside. I can add a node of type ICPPASTNamespaceDefinition for this abstract machine, only because its syntax is similar to a namespace but actually has nothing to do with a namespace. This is not a good work around. I can extend IASTNode (ignoring the noextend annotation) and add a custom node but the indexer is not going to understand it nor is the outline view.

Another problem is that "@abstract machine" needs highlighting. I can add the two language keywords "abstract" and "machine" to have it highlighted, but that will also highlight only "machine", if someone uses that as a variable identifier. Creating one token for "@abstract machine" would require to change the Lexer. The Lexer class is declared final, so the behavior of the Lexer can only be customized in a very limited way. Using Semantic Highlighting doesn't work either, because the abstract machine needs to be parsed as IASTName then (but it's a declaration, so it should be parsed as IASTDeclaration).

A related problem is displaying syntax errors for incorrect usage of RT-Tester-Concepts. There are about 60 RT-Tester commands and the only support I can provide currently is that the commands are ignored by preprocessor or parsed as something different by the parser, so that the AST is built up without problems and features like "go to declaration" or "call hierarchy" work as expected.

Another problem might occur when the indexer tries to resolve file paths, because our files usually remain on a server. Another problematic RT-Tester-Concept is a "channel", which is declared  in a cnl-file (*.cnl). In the declaration of variables used to write/read from a channel, a channel type definition has to be used which is the channel identifier appended with "_t". Now the indexer will not find <channel_name>_t as it has never been declared. I can rename token images but that comes with undesired side effects.

I could mention more examples, but I home the motivation, why we want to check whether a fork is a good choice, becomes clear.
And the main question is: What is the correct/best way to fork CDT if I only want to change functionality in the core plugin?

Thank you,
Sadik

-- 
Sadik Özoguz
Verified Systems International GmbH
Geschäftsführerin Dr.-Ing. Cornelia Zahlten
HR B 18341 Amtsgericht Bremen
Am Fallturm 1
28359 Bremen, Germany
mail: soezoguz@xxxxxxxxxxx
tel:   +49 421 572 04-286
fax:   +49 421 572 04-22
http://www.verified.de

Back to the top