On Aug 2, 2011, at 8:11 AM, 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?
I still dont understand the concern here. GCC is already picking a default for
-mcpu, so why is having a tune file pick a better default any issue?
If there is an explicit -mcpu or other options like -mtune, the setting of
--with-cpu will get ignored.
- k
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
