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