[oe] introducing a new architecture/machine; policy ? (and a question)

[Frans Meulenbroeks]

2010/6/23 Khem Raj <raj.khem at gmail.com>:
> On (23/06/10 12:09), Frans Meulenbroeks wrote:
>> 2010/6/23 Koen Kooi <k.kooi at student.utwente.nl>:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > On 23-06-10 10:53, Frans Meulenbroeks wrote:
>> >> 2010/6/20 Frans Meulenbroeks <fransmeulenbroeks at gmail.com>:
>> >>> 2010/6/20 Koen Kooi <k.kooi at student.utwente.nl>:
>> >>>> -----BEGIN PGP SIGNED MESSAGE-----
>> >>>> Hash: SHA1
>> >>>>
>> >>>> On 20-06-10 11:58, Frans Meulenbroeks wrote:
>> >>>>> Hi,
>> >>>>>
>> >>>>> I'm about to complete bringing a new architecture (nios2 with mmu) and
>> >>>>> machine (cyclone III FPGA starter kit, and maybe also the Nios2
>> >>>>> Embeddeded Evaluation Kit (aka neek)) to oe.
>> >>>>> Is there a policy on on the process how to do this.
>> >>>>
>> >>>> Have a look at the nios2 patches Leon sent last december, they were
>> >>>> reviewed on this list, but not committed.
>> >>>
>> >>> Koen, thanks for reminding me the look at the review comments.
>> >>>
>> >>> I'm well aware of the work of Leon and Walter (and they are well aware
>> >>> of my work).
>> >>> Note that what Leon posted was for a non-mmu nios2 core, whereas the
>> >>> changes I have is for an mmu core.
>> >>>
>> >>> Triggered by Koens reminder I revisited the review comments. Actually
>> >>> none but one are applicable for me.
>> >>> The one that is applicable is the one about pinning versions in
>> >>> machine descriptions.
>> >>> I have also done that, as there are simply no other versions of
>> >>> binutils and gcc that can be used by this hardware.
>> >>> Also I don't feel empowered to make changes in distribution specific files.
>> >>>
>> >>> The only alternative way that I can think of is doing something like:
>> >>> DEFAULT_PREFERENCE_nios2 = "1" in the recipes I need.
>> >>> No idea if that overrules the distro settings or not, but I can give
>> >>> it a try later today.
>> >>
>> >> Well, tried it and apparently a distro pin has priority over a
>> >> DEFAULT_PREFERENCE_nios2 in the recipe.
>> >> Guess I'll have to do the pinning the the machine description as
>> >> described above.
>> >
>> > NO! Machines *never* pin versions, that's what distros and to a lesser
>> > extent recipes are for.
>>
>> The issue is that I have no way to specify which versions of a
>> toolchain that are supported (and to enforce that only a supported
>> version works).
>> If the DEFAULT_PREFERENCE in recipes had priority above whatever a
>> distro pins using DEFAULT_PREFERENCE in the recipe could work.
>> (e.g. if  DEFAULT_PREFERENCE = "-1" does mean something like: "does
>> not work" and that is respected by the distro).
>>
>> Actually I do not want the machine to pin the recipe, I want the
>> architecture to pin the recipe (or at least tell which versions are
>> sound, and avoid that non-functional versions are used).
>
> you can use the TARGET_ARCH override to do that

I'm not fully sure how one would actually do that.Please explain it to
me on irc.

>>
>> If I cannot pin in a machine file, the only alternative seems to be to
>> make gcc-nios2-* recipes and use a virtual/gcc in the conf file to
>> select gcc-nios2 as the preferred versions (just like a lot of
>> machines do with virtual/kernel). Seems like a waste of effort to me,
>> but oh well
>
> Already suggested a solution in prior reply.

I can pin in sane-toolchain, but only a few distro's seem to use that.
For now I think it is probably best to have gcc-nios recipes and
define virtual/gcc in the machine configurations. (haven't really seen
objections to that, and for virtual/kernel this seems common practise)
The best solution is indeed to have a sane-toolchain.inc that defines
the available versions for an architecture and that is used by every
distro, but somehow I doubt if that will happen.
>
>>
>> BTW where did the rule come from that machines never pin versions?
>> When was that decided?
>> And as an owner of the machine file, isn't its contents something
>> which is at my discretion ???
>
> Well yes but within bounds of design and common structure. You dont get a license to
> kill with maintainership if you know what I mean :)

I know what you mean, but I don't like it if people sell me crap like
"NO! Machines *never* pin versions" while within a few seconds I can
provide evidence that there are not one or two, but 71 machines that
pin something in their conf.

Frans.

>
>>
>> And as a final remark:
>> I did a quick grep in conf/machine:
>> $ grep PREFERRED_VERSION * -l | wc
>>      71      71    1065
>> $ grep PREFERRED_VERSION * | wc
>>     104     314    5761
>>
>> So there are 71 machine descriptions that pin at least one package. In
>> total these 71 contain 104 pins.
>> Most of these pin kernel and/or u-boot but there are also two other
>> machines that pin gcc.
>>
>> 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
>