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 Matt,

On Tue, Oct 16, 2012 at 6:31 PM, Matt Jervis <matt.jervis@xxxxxxxxxxxxx> wrote:
Hi all,

I am currently trying to implement a custom project creation wizard that generates a CDT C project, but I am having some difficulty with this and I would be grateful for any help that can be offered.

My current goal is to implement a plugin that programmatically generate a project which uses a GCC toolchain for cross compilation.  The GCC toolchain is located at an arbitrary path and has an arbitrary prefix, both of which are passed to the project generation code.

The problem that I am struggling with currently is programmatically setting up the toolchain when creating a new project.  I have had some success setting up a new project of type cdt.managedbuild.target.gnu.cross.exe, and for each configuration calling:
config.getToolChain().getOptionById("cdt.managedbuild.option.gnu.cross.prefix").setValue(prefix);
config.getToolChain().getOptionById("cdt.managedbuild.option.gnu.cross.path").setValue(path);

This gives me a project with the correct toolchain selected and correct values for prefix and binary path.  However, I am running into issues with discovery of include paths, etc.  My understanding is that I should be using the new Language Settings Providers mechanism for discovery rather than the pre-8.1 discovery method.  However, I am not sure that I understand how to use Language Settings Providers properly, so have a few questions relating to these.

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?
 
 * 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.


Thanks,
Andrew


If anyone can offer some guidance on this it will be greatly appreciated.

Best regards,
Matt

--
Matt Jervis | Virscient Limited
Ruakura Research Centre, East Street, Hamilton 3214, New Zealand
Email: matt.jervis@xxxxxxxxxxxxx | Web: www.virscient.com

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top