2010/6/23 Khem Raj <[email protected]>: > On (23/06/10 12:09), Frans Meulenbroeks wrote: >> 2010/6/23 Koen Kooi <[email protected]>: >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > On 23-06-10 10:53, Frans Meulenbroeks wrote: >> >> 2010/6/20 Frans Meulenbroeks <[email protected]>: >> >>> 2010/6/20 Koen Kooi <[email protected]>: >> >>>> -----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 >> [email protected] >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
