| Project that use multiple compilers [message #1761155] |
Mon, 08 May 2017 10:17 |
 Robert Kiss
Messages: 10
Registered: July 2009 |
Junior Member |
|
|
Hello
I would like to get your opinion regarding a particular scenario that we have.
We need to provide to our customers a CDT based IDE that will allow them to build and test C/C++ projects that need two different compilers to build, one is a GCC based compiler while the other one is a LLVM based one. The projects already exists and can be build using make from command line.
We don't have the option to create inside Eclipse two projects, each with their own toolchain, which from what I heard would be the ideal solution.
Until recently we just had a Makefile project where we added a custom Language Settings Provider to advertise the default settings for one of our compilers and one Build Output Parsers configured to look for the output of both compilers and store the settings at project level.
This was obviously wrong for a couple of reasons:
- The compilers had different system includes and different system defines. Because the indexer is aware only about one of the settings, all the files that get compiled with the other compiler will use wrong settings.
- Storing the settings at project level will also confuse the indexer.
To solve all this problems we need to have somehow two index databases. Checking the AbstractIndexerTask class we found out two possible ways to do that:
- Have two linkages defined, one for each compiler.
- Advertise the files as having different languages. Note that all files uses standard C/C++ extensions disregarding the compiler being used.
We manage to implement the second found way, and we did the following:
- We defined a new content type for C source and header files using org.eclipse.cdt.core.cSource/Header as base types. We had to set the priority to low because we don't want CDT to use them all the times.
- We contributed a new cdt language (see org.eclipse.cdt.core.language extension point) and map them to our content types. They advertise the same LINKAGE_ID as GCCLanguage. This new language will be associated with one of the compilers while the other will use the CDT provided GCCLanguage.
- We contribute two Language Settings Provider, one for each compiler, that will be used to resolve the corresponding system includes and defines.
- Two Build Output Parser had been contributed, one for each compiler, with the following content:
- the determineLanguage method will return the corresponding language, either the default cdt language or the one contributed by us.
- we override setSettingEntries method in order to store the right language for each file. Unfortunately we were not able to do that during console parsing because the workspace would be changed which will trigger the indexer so we had to postpone that to happen right before Indexer runs.
- Because of the previous issue, we had to contribute our own indexer (see org.eclipse.cdt.core.CIndexer extension point) that will return our own IPDOMIndexerTask implementation.
- When our IPDOMIndexerTask is executed it will first set all necessary file language mappings (see method ProjectLanguageConfiguration.setFileMappings) and then it will simply delegate the execution to the CDT PDOMFastIndexerTask class.
- Unfortunately, during indexing when language is resolved it tries to get an IScannerInfo and for this it needs an IScannerInfoProvider (see TranslationUnit.getScannerInfo). The default implementation (see LanguageSettingsScannerInfoProvider.getScannerInformation) uses a call to LanguageSettingsManager.getLanguages which it should return the right language because it was set by the indexer. However, looking at the implementation it first call the deprecated method ICConfigurationDescription.getLanguageSettingForFile which just return the language based on file extension.
- To solve the previous issue we had no other choice but to use AspectJ to fix the LanguageSettingsManager.getLanguages method.
Our approach works, for example depending on what we drop in the Include Browser view it will show that system include <stdio.h> is resolved either in the system folder of one compiler or the other compiler. Also, if I open after a full successful build any file from the project all symbols and includes are resolved and any Open Declaration action is successful.
But I cannot ask myself if this approach is the right approach. We had to extend some internal classes, or to re-implement some (eg PDOMFastIndexerTask have package access so we cannot use it directly). And because we had to use AspectJ everything have the potential to blow with each upgrade.
What do you think about this? Are there any better way to achieve this? How would you do it?
Regards
Robert Kiss
|
|
|
Powered by
FUDForum. Page generated in 0.02640 seconds
] 
Search
Help
Register
Login
Home
