[OE-core] [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Kumar Gala]

On Aug 2, 2011, at 8:42 AM, Richard Purdie wrote:

> On Tue, 2011-08-02 at 08:11 -0500, Kumar Gala wrote:
>> On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote:
>> 
>>> On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
>>>> On 08/01/2011 09:07 AM, Phil Blundell wrote:
>>>>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
>>>>>> Not sure I understand the statement about disambiguate the resulting compilers, on PPC where I intend to utilize this we'd have the toolchains already named something like:
>>>>> 
>>>>> The thing about disambiguating was that, if you're going to modify the
>>>>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
>>>>> to consider what happens if you have a single build directory that's
>>>>> being used for multiple MACHINEs.
>>>> 
>>>> What, I think, Kumar is driving at is why are you saying MACHINE when
>>>> it's a per core tune he's doing.  eg, every e5500 would do --with-cpu=e5500
>>> 
>>> The question is whether we'd like to get to the point of having more
>>> toolchains or less toolchains. I'd personally like to get to the point
>>> of less toolchains (e.g. one per arch) rather than more of them. We
>>> already pass all the appropriate flags around in the ADT/sdk code and in
>>> our own cross builds, we could easily add those to the default target
>>> environment too. This would actually make it clearer what is going on to
>>> the end user too rather than hiding the details into the gcc
>>> compilation.
>>> 
>>> So all things considered, I don't think this is the best way to go...
>>> 
>> 
>> How is this done or exported to the user of an ADT/sdk toolchain?
> 
> There is a script included in the toolchain tarball which contains the
> appropriate information. I don't have one handy to check but I suspect
> Jessica will have. Jessica?
> 

Ping on this script?

- k