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
_______________________________________________