Re: introducing a new architecture/machine; policy ? (and a question)

[Khem Raj <raj.khem@gmail.com>]

On (23/06/10 12:09), Frans Meulenbroeks wrote:
> 2010/6/23 Koen Kooi <k.kooi@student.utwente.nl>:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 23-06-10 10:53, Frans Meulenbroeks wrote:
> >> 2010/6/20 Frans Meulenbroeks <fransmeulenbroeks@gmail.com>:
> >>> 2010/6/20 Koen Kooi <k.kooi@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
> 
> 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.

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

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