Re: [PATCH] gcc: Add ability for tune files to pass in configure options to gcc

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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


Cheers,

Richard