commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Things like this:

+LIBC = "glibc"
+ANGSTROMLIBC = "${LIBC}"

+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"
+PREFERRED_VERSION_glibc = "2.5"
+PREFERRED_VERSION_glibc-initial = "2.5"

+PREFERRED_VERSION_busybox_nios2 = "1.13.2"

+ASSUME_PROVIDED += "linux-libc-headers-native"

do NOT belong in a machine.conf (or machine include). Those belong in
the distro (or local.conf), not in the machine.

So please, move the offending bits into a distro include (minus the
assume provided) to stop this kind of bad example from spreading further.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMM6ZlMkyGM64RGpERAh0WAKCCFMbPN9oeqRa89Kfn5LBlhCCFmgCglgkF
WOZqYLRBYTgof3G9nIgyYUQ=
=iST9
-----END PGP SIGNATURE-----

Re: commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

[Tom Rini]

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

-- 
Tom Rini
Mentor Graphics Corporation

Re: commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

[Koen Kooi]

-----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.
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.
And not to mention the need to change DISTRO_PR for editing a
machine.conf, that's just backwards.

> 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 :)

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.

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?

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMNConMkyGM64RGpERAon3AJ9keLb8YBEVmCsvWzhEqb3qtLCWKgCfcX+4
kuDgy1Jqhl4qdAIVEWkiTfc=
=0Lny
-----END PGP SIGNATURE-----

Re: commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

[Frans Meulenbroeks]

2010/7/7 Koen Kooi <k.kooi@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

Re: commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07-07-10 10:22, Frans Meulenbroeks wrote:

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

Both me and Graemo have told you that in that RFC thread, that's 2/3 of
the angstrom core developers already.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMNDsUMkyGM64RGpERAo+7AJ0cyzYELBJ/RM4bT6CGG5AwoEYNaQCfVJDf
EgWdJiOPiLdH3pPCXYUKTWY=
=5bcf
-----END PGP SIGNATURE-----

Re: commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

[Frans Meulenbroeks]

2010/7/7 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07-07-10 10:22, Frans Meulenbroeks wrote:
>
>> - 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)
>
> Both me and Graemo have told you that in that RFC thread, that's 2/3 of
> the angstrom core developers already.

Graeme mentioned that if I asked, it might be added. One might
consider that as interest.
From you I have not seen a message that I interpreted as interest from
the angstrom side.
(and if that is a misinterpretation from my side, my apologies for that).

Anyway, I have no interest in having a yes/no discussion on whether or
not angstrom has shown interest.
If angstrom wants to support nios2, fine with me. If not, also no problem.

There is a machine.conf. I feel it serves its needs. The rationale why
things are added is well documented. Pinning things in a machine conf
is afaik not in violation with any OE design rule, and also not
uncommon as 100+ pinnings in the machine dir tell me.

But if you feel my machine conf file is totally wrong feel free to
raise the issue with the TSC.
(then again I have not seen too much explanation why this is bad; I
just reread the first post of this thread and there is no explanation
why this is bad; maybe it helps if you consider something is bad, that
you explain why it is bad, instead of just making statements that
things are bad. In general by explaining why something is bad you
create understanding. Saying that something is bad without saying why
is only creating anger and frustration).

Frans.


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFMNDsUMkyGM64RGpERAo+7AJ0cyzYELBJ/RM4bT6CGG5AwoEYNaQCfVJDf
> EgWdJiOPiLdH3pPCXYUKTWY=
> =5bcf
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

[Philip Balister]

On 07/07/2010 04:22 AM, Frans Meulenbroeks wrote:
> 2010/7/7 Koen Kooi<k.kooi@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)

Frans, Angstrom devs are commenting on your work. That is interest.

Philip


>    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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

[Khem Raj]

On Wed, Jul 7, 2010 at 1:22 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2010/7/7 Koen Kooi <k.kooi@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.

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.

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

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

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


>>
>> 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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

[Frans Meulenbroeks]

Khem, thanks for your informative and constructive reply.

Below some response

2010/7/8 Khem Raj <raj.khem@gmail.com>:
> On Wed, Jul 7, 2010 at 1:22 AM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
>> 2010/7/7 Koen Kooi <k.kooi@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@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

[Khem Raj]

On Wed, Jul 7, 2010 at 12:17 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> -----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.
> 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.
> And not to mention the need to change DISTRO_PR for editing a
> machine.conf, that's just backwards.
>
>> 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 :)
>
> 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.
>
> 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?

yes it belongs to distro. Logically machines pin machine specific things
toolchain is more akin to distro than a machine. Its how OE is designed.
I agree with Koen here. If you propose fixes for say sane-toochain.inc
many other distro will support nios2.

>
> regards,
>
> Koen
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFMNConMkyGM64RGpERAon3AJ9keLb8YBEVmCsvWzhEqb3qtLCWKgCfcX+4
> kuDgy1Jqhl4qdAIVEWkiTfc=
> =0Lny
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

[Tom Rini]

Koen Kooi wrote:
> -----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.
> 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.
> And not to mention the need to change DISTRO_PR for editing a
> machine.conf, that's just backwards.

machine.conf directly is bad, agreed.  So again, thinking out loud a bit 
here, perhaps a good bit of, if not all of the current 
machine/include/tune- files should be under conf/distro/include/ (cpu/ 
?)  How do we optimize (or rather, optimize harder), feed / package 
arches, that too is all distro stuff.

>> 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 :)

Yes, make it easy for people to get what they want working right.

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

That last part is where I'm unconvinced.  And I'm also not suggesting 
that every CPU architecture lock program versions down.  But it should 
be as easy as possible to add a machine and have it Just Work.  As it 
stands today there's already (and as you allude to, bit rotten at times) 
lock platform X to version Y overrides in Angstrom.

What I'm trying to say, and I'm not picking on Angstrom here, just using 
this as an example, I think it'd be better if ppc405/xilinx-ml403 gcc 
lockdowns lived somewhere more obvious to all because it's either 
universally true or universally bunk, 9 times out of 10.

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

I'm going to look at this from my old hat (as I think there's other 
people on the list, lurking or not that are in that kind of situation). 
  It's quite possible that next week I'll have a contract to work on 
NIOS2 and it'd be real nifty if I could just include the right file and 
things work.

-- 
Tom Rini
Mentor Graphics Corporation

Re: commit 4d6a63850b4dc7ca2f060aedda26ddf4efa0e5cc

[Frans Meulenbroeks]

2010/7/6 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Things like this:
>
> +LIBC = "glibc"
> +ANGSTROMLIBC = "${LIBC}"
>
> +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"
> +PREFERRED_VERSION_glibc = "2.5"
> +PREFERRED_VERSION_glibc-initial = "2.5"
>
> +PREFERRED_VERSION_busybox_nios2 = "1.13.2"
>
> +ASSUME_PROVIDED += "linux-libc-headers-native"
>
> do NOT belong in a machine.conf (or machine include). Those belong in
> the distro (or local.conf), not in the machine.
>
> So please, move the offending bits into a distro include (minus the
> assume provided) to stop this kind of bad example from spreading further.

Being the one who made the commit I'd like to make a few remarks.

First of all I suggest that if you quote text, you also quote the
comments that go with the text you quote:

# for now we pin gcc, glibc and binutils
# as these are the only versions that have
# nios2 support.
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"
PREFERRED_VERSION_glibc = "2.5"
PREFERRED_VERSION_glibc-initial = "2.5"

# uclibc does not work yet
# PREFERRED_VERSION_uclibc = "0.9.30.3"
# PREFERRED_VERSION_uclibc-initial = "0.9.30.3"

# for now busybox 1.13.2 is the only one
# patched and tested for nios2 so pin this
# one too, until the other versions are updated
# for nios2 too.
PREFERRED_VERSION_busybox_nios2 = "1.13.2"

# there are some issues cross-compiling when
# using linux-libc-headers-native as we get
# some native inc dirs when compiling crt stuff
# ASSUME_PROVIDED fixes this (but breaks compilation
# on old host systems like red hat 4.
ASSUME_PROVIDED += "linux-libc-headers-native"

Secondly, pinning LIBC to glibc in a machine conf or include is indeed
not too desirable but as neither uclibc or eglibc are working for this
architecture I needed a way to indicate this.
If there is a better solution for this, please let me know.

Next wrt the busybox pinning: this is just a temporary as indicated by
the comment. It'll disappear for sure in the near future (after I had
time to look at later busyboxes and fix those).

Wrt the ASSUME_PROVIDED += "linux-libc-headers-native":
I'll happily remove it once the include badness introduced by
linux-libc-headers-native is fixed. (there is a different thread on
this).

And finally the pinning of gcc/binutils/glibc.
I feel the machine (and not the distro) is the one who should be able
to specify which version(s) work for that machine and what the
preferred version is.
That is: for gcc and binutils. glibc might be a different case.
It might be that a distro wants to override this, and I can imagine we
want to support that. I'd say overriding in such a case is done on an
architecture or machine base, not in a generic override.

Note also that the current machine description makes things working
for *all* distros, whereas without it it would probably not be working
for any distro at all!

And lastly I am unaware of any place in the oe manual which states the
above is bad behaviour (and why this is bad).

Frans.

PS: as mentioned before there are currently 100+ pinnings in
conf/machine/* and conf/machine/include/* and at least two other
machines pin gcc

PPS: adding a new architecture to oe is quite some work. Picking on
people does not really encourage to contribute that work. I could have
equally well have kept this local.