[oe] commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

[Frans Meulenbroeks]

2010/7/7 Koen Kooi <k.kooi at student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07-07-10 00:49, Tom Rini wrote:
>> Koen Kooi wrote:
>>
>>> +PREFERRED_VERSION_gcc-cross = "4.1.2"
>>> +PREFERRED_VERSION_gcc-cross-initial = "4.1.2"
>>> +PREFERRED_VERSION_gcc-cross-intermediate = "4.1.2"
>>> +PREFERRED_VERSION_binutils = "2.17.50.0.12"
>>> +PREFERRED_VERSION_binutils-cross = "2.17.50.0.12"
>> [snip]
>>> do NOT belong in a machine.conf (or machine include). Those belong in
>>> the distro (or local.conf), not in the machine.
>>
>> Just putting this out there (and it's indeed _not_ how things are
>> today).  Why would we not want to move towards having this kind of stuff
>> be in the tune-ARCH.inc file, when a specific version is really needed
>> (more avr32 or new'ish core on an existing overall arch) ?
>
> Putting it in a tune-arch is not a problem, just put it in
> conf/distro/include.

Why should this be distro specific. I'd say this is generic.

> Experience has shown that putting it the machine includes is a bad idea,
> It rots and after a while a new machine gets added that doesn't use said
> machine include.

I'm not sure how it would rot, but anyway I'd say avoiding this is the
responsibility of the architecture maintainer. (which might well be
the one who maintains gcc for that arch).
Wrt the "new machine gets added that doesn't use said machine
include": I agree this is a risk.
To me it seems part of the problem is that architectures seem 2nd
class citizens. Ideally boards should link to architectures.
(btw: I'd say a new board gets added that does not use said
architecture include).

It might be an idea to restructure the conf/machine dir to turn it into a
conf/architecture/board hierarchy.

> And not to mention the need to change DISTRO_PR for editing a
> machine.conf, that's just backwards.

As said this is because architectures are 2nd class citizen. I feel it
would be better to add an ARCH_PR.
(actually by introducing an ARCH_PR, it might be that the need for
DISTRO_PR diminshes or goes away, can't fully judge that atm).

>
>> Yes, it
>> should be up to the distro to say "we want 4.4.x + 2.20.x" or whatever,
>> but then we also get the downside of "special case, XXXX only works well
>> with 4.3.4 + 2.19.x" or what have you, and those special cases get
>> introduced in one place and copy/pasted elsewhere.
>
> So you have an include file in conf/distro that people can optionally
> use or copy/paste. Not all distros can/want to support all machines in
> OE. Angstrom tries to, but that's because it's the reference implemention :)

I'm not sure if Tom is saying that.

Anyway, as the maintainer for the nios2 toolchain I don't feel like
chasing down all distro's and making sure they fix their stuff if e.g.
a certain version of gcc has to be deprecated (e.g. because it is
broken)
>
> It boils down to this:
>
> The distro needs to make a decision to do strange stuff to support a
> platform. Silently forcing it is bad.

I object to calling this "do strange stuff".
>
> In this specific case no distro except angstrom has expressed interest
> in supporting nios2, so we could even but this in an angstrom.inc.
> Seriously, can the distro maintainers that are willing to support nios2
> please raise their hands?

A few comments here:
- I haven't really seen interested from angstrom to support nios2.
Feel free to correct me by sending a pointer (preferably referring to
the angstrom mailing list)
  Actually, except for Leon, I am unaware of any serious interest.
- I've no idea how many active distro maintainers we have.
- and I am not sure how many of them will read this thread.

Anyway, I am dealing with a distro (unpublished as of now) which is
interested in nios2.

Frans