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
_______________________________________________