Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Language Settings Providers and toolchain prefixes
Hi Andrew,

Thanks for taking the time to reply to my email.

On 18/10/12 02:58, Andrew Gvozdev wrote:
<snip>
If I understand correctly, the provider 'CDT GCC Builtin Compiler Settings' is used to get information about include paths, etc. from the compiler.
 * Is it correct that the provider 'CDT Managed Build Settings Entries' enables the deprecated 'Discovery Options'?
In a sense. MBS language settings provider is intended to provide entries for indexer which are coming from managed build plugin. As such, it provides entries of deprecated "Discovery Options" (they are part of MBS) when they are enabled on the property page.
 * Does this then mean that it is thus superseded by 'CDT GCC Builtin Compiler Settings'?  I have been working under this assumption.
The language settings providers are independent from each others. You can enable/disable them as you see fit, that includes MBS provider. The first provider in the list wins in case of conflicting entries.
 

When I create a project manually using the 'C Project' wizard (setting the toolchain path and prefix in the wizard), and select only the providers 'CDT GCC Builtin Compiler Settings' and 'CDT User Setting Entries', I get an error 'Program "gcc" not found in PATH'.  I can get rid of this error if I change the 'Command to get compiler specs' parameter of 'CDT GCC Builtin Compiler Settings' from
  ${COMMAND} -E ...
to
  arm-none-eabi-${COMMAND} -E ...

(where arm-none-eabi- is the prefix for my toolchain).

 * Is this the correct approach?
 * Should ${COMMAND} include the prefix? if not, is there a variable I can use to get the prefix (e.g., ${PREFIX}${COMMAND})?
The intention was to use/reuse variables from managedbuilder plugin. For some reason, it does not define ${PREFIX} variable. I think we should be consistent here. I did not work much with cross compilers but perhaps ${PREFIX} should be added to both places?

Yes, I think that it would make sense for there to be a ${PREFIX} variable to get the prefix from the toolchain, and it would also make sense for the default command to get compiler specs parameter to use ${PREFIX}${COMMAND} rather than just ${COMMAND} since ${PREFIX} would simply be empty if there was no prefix defined.
 
 * If I do need to change the 'Command to get compiler specs' is it possible to do this programmatically?
Yes, it should be possible. Take a look at JavaDoc for ILanguageSettingsProvider, AbstractBuiltinSpecsDetector and ToolchainBuiltinSpecsDetector. Let me know if you have difficulties with that.
I have achieved what I wanted by declaring a new language settings provider in my plugin.xml; this provider uses the GCCBuiltinSpecsDetector class and has a customised parameter attribute (just the default value with the toolchain prefix prepended).  I then have a custom project type in which I define configurations that have this provider and the User Settings Provider as their language settings providers.  The only issue I have is that the check boxes next to the language settings providers in the Providers tab of project properties stay unticked until I close and reopen the project; this is not really a problem for me since I just have the project generation code close and reopen the project before it finishes.

Based on what I have done so far, it appears that the language settings providers only provide include paths, marcos, etc. for the indexer, and don't contribute to the actual build.  I.e., if I create a language settings provider that defines some macros, these macros don't appear on the commandline when a build is invoked.  Is my understanding correct, or am I doing something wrong?  If this is correct, then what is the proper way of passing such information to the actual build system? Should I be using the 'Paths and Symbols' page of project properties?  The reason that I am not at present is that I have the 'CDT Managed Build Settings Entries' provider disabled in order to disable the legacy discovery support, and that means that the information entered on the Paths and Symbols page is not used by the indexer.

Thanks again for your help.

Regards,
Matt

Back to the top