| RE: [cdt-core-dev] Extending includes resolving algorithm |
It would be mostly programmatic and it would be a hack.
You can contribute your own ILanguage, which is the parser's interface, via the org.eclipse.cdt.core.language extension point. Take a look at the AbstractCLikeLanguage class in CDT which implements ILanguage. This class has two subclasses for the C and C++ parsers which are GCCLanguage and GPPLanguage respectively.
Now, the getASTTranslationUnit() method is what runs the parser, it is passed an argument of type ICodeReaderFactory. A code reader factory is responsible for resolving include directives and returning a char[] buffer with the contents of the file that is being included. The code reader factory is used to instantiate the preprocessor by calling the createScanner() method. What you need to do is create subclasses for GCCLanguage and GPPLanguage and override createScanner() in both. In your version of createScanner() take the coderReader parameter and wrap it in your own adapter. Your adapter will intercept the call to createCodeReaderForInclusion() and provide your own include resolution logic.
Then you have to take care of the fact that CDT maps the C and C++ content types to GCCLanguage and GPPLanguage by default. You can programmatically set the language mappings to your own ILanguages when creating a project but I'm not sure off the top of my head how to do that.
Yeah, so, not very pretty. But if you are desperate at least it can be done.
Mike Kucera
Software Developer
IBM Eclipse CDT Team
mkucera@xxxxxxxxxx
AlexanderMaltsev ---04/24/2009 05:03:41 AM---Thanks. How can I substitude a standard ICodeReaderFactory implementation to
From: | AlexanderMaltsev <maltsev_alex@xxxxxxx> |
To: | cdt-core-dev@xxxxxxxxxxx |
Date: | 04/24/2009 05:03 AM |
Subject: | RE: [cdt-core-dev] Extending includes resolving algorithm |
