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

[Frans Meulenbroeks]

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

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

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

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.