Re: [linuxtools-dev] autotools plug-in extensibility

[Corey Ashford <cjashfor@xxxxxxxxxxxxxxxxxx>]

On 04/21/2011 12:19 PM, Jeff Johnston wrote:
> Hi Corey,
> 
> You are correct in that you cannot add new options to the Configuration
> Settings pages except via code.  The AutotoolsConfiguration has the set
> of options and the Configuration Settings pages are created based on
> them.  This was done to make the code easily extendible if we wanted to
> add some missing options that were common enough.
> 
> I'm not sure why you don't want to use the existing mechanisms for
> specifying options that are not in any of the configuration setting pages.
> 
> The user field is a free form way to add any configuration options you
> want.  For example, this is where you would add --with-xxxxx and
> --enable-yyyy options which are not provided elsewhere in any of the
> options pages.
> 
> You can also modify the configure command itself and there you can add
> environment variable settings.
> 

> The options themselves are stored in xml format in the .autotools file
> that is stored with the project.  This includes the configure command
> itself.  When an autotools project is loaded, the .autotools file is
> read in and this is used to fill in the fields of the Configuration
> Settings.
> 
> Does this help?

Thanks for your quick reply, Jeff!

Yes, this helps in that it confirms what I saw in the code.
Unfortunately doesn't solve the issue we have as far as I can tell.

Here's our situation:

We are developing an SDK for Linux on POWER (IBM POWER architecture).
The SDK is based on Eclipse + CDT + Linux Tools Project + one
proprietary plug-in for a tool called FDPR.

We want this SDK to default to using the IBM Advance Toolchain, which is
a very recent GNU toolchain, with the latest optimizations, and code
generation capability for the latest POWER chips (e.g. POWER7).

When a user creates an Autotools project, we want that project's gcc/g++
compiler to default to our AT toolchain, not to whatever happens to be
on their PATH.

To utilize the .autotools file for this purpose, we'd have to add some
sort of hook that would auto-magically add the "Additional options" to
the .autotools file (and internal representation) as the project was
being created.  We don't want to require the user to add these options
themselves, either by modifying the configure command or by adding
additional options.

I can post up a patch that adds the ability to set configure's variables
as a new option type (in addition to BIN, STRING, INTERNAL, and
MULTIVAR).  I used this new code to add the ability to set the CC and
CXX vars.  Even with this patch, though, I still need the defaults set
to point to the AT toolchain via Java code which then becomes part of
the plug-in.  So to utilize this code, we will have to modify the
autotools plug-in source, then build and ship that instead of the stock
plug-in.

Ideally, we'd like to be able to extend existing configuration options
in a similar way to how they are managed for CDT toolchains, and that is
by utilizing its exposed extension point and adding XML code to add the
needed options or even completely new toolchains.

Thanks for your consideration,

- Corey