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

[Khem Raj]

On (23/06/10 22:04), Frans Meulenbroeks wrote:
> 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.
> 

as I said see AVR32 in sane-toolchain.inc

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

distro's are fairly independent so if you intend to support so many of them
and then you have change distro files accordingly.

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

why do you want to compicate already complicated gcc recipes and
mechanisms. Goal should be to consolidate not to diverge.

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

well even this does come with some pricetag. There is a downside to it that changing
versions in sane-toolchain.inc would require qualification on all distro's
that use it. so more distro's harder it will be. But it could be an
achievable goal but thats distro maintainer's choice and I am fine with
whatever they choose.