[oe] commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

[Frans Meulenbroeks]

Khem, thanks for your informative and constructive reply.

Below some response

2010/7/8 Khem Raj <raj.khem at gmail.com>:
> On Wed, Jul 7, 2010 at 1:22 AM, Frans Meulenbroeks
> <fransmeulenbroeks at gmail.com> wrote:
>> 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.
>
> We generally categorize distro to support many machines/architectures
> and commonolize on toolchain because 2/3 of gcc is common for all architectures
> and if a bug gets fixed in front end of middle end all architectures benefit
> if you start locking compiler versions per machine it will pave way to chaos
> as you will be using different compiler for every machine.

I didn't look at it from the gcc commonailty perspective.
When it comes to paving way to chaos, I have some doubts.
I haven't created a new version of gcc (that's why I explicitly didn't
go the gcc-nios2 recipe way).

And actually the chaos is already there. Personally I feel we have way
too many gcc recipes. (21 different versions, not counting the
cross-initial, cross-intermedate, cross, *sdk* *csl* etc ones).
But this has been discussed before and as far as I am concerned we do
not need to rehash that discussion.

>
> sometimes some machines use same family of processor like say omap5912osk and
> qemuarm they can use same toolchain if one is compiling for both in
> multimachines.

I'd say the same toolchain can be used (and generally is used) if it
is the same architecture.
>
>>
>>> 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.
>
> thats a good suggestion.
>
>>
>>> 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).
>>
>
> DISTRO is sort of profile which drives the software compilation now
> if you intend to hijack its purpose and put it in machine conf you can
> very well do it but its not norm.

I have no desire to hijack DISTRO.
>
>>>
>>>> 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.
>>>
>
> whats problem with that. Your patch does same instead of distro it puts it
> in machine confs. I dont know why you dont like how AVR32 is done.

Note that the text quoted above (starting with Yes, it) is not mine
whereas the rest of the text
you reply to is mine.
>
>>> 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)
>
> so how do you think nios users will use this stuff. I guess they dont
> need a DISTRO is that what you are intending ?

Well I'm using my own for now.
As I felt it others might be interested in and benefit from my work,
that's why I made it available.
As it helped to get acceptance I've added a board definition for a
publicly available board (normally I run this on our own embedded hw).
If a distro wants to support the board, fine with me. If not, equally
fine with me.
The only issue is that for now there is only a backend for gcc
4.1.2/binutils 2.17.50.0.12
Generally speaking this means there should be a way to specify that an
architecture is incompatible with a certain tool vendor.
(and I feel enforcing this one way or another is better than letting
things fail and leave the user to find out why the heck this
combination of machine and toolchain is not working).

Have fun, Frans
>
>
>>>
>>> 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
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>