Op 15 jun 2011, om 13:36 heeft Richard Purdie het volgende geschreven: > On Wed, 2011-06-15 at 12:37 +0200, Koen Kooi wrote: >> Op 15 jun 2011, om 12:22 heeft Richard Purdie het volgende geschreven: >> >>> On Wed, 2011-06-15 at 12:15 +0200, Koen Kooi wrote: >>>> Op 15 jun 2011, om 12:07 heeft Richard Purdie het volgende geschreven: >>> I know, but we have two choices: >>> >>> a) Continue this spiral of confusing variable names, conflict and wacky >>> bugs >>> >>> b) Come up with a plan to address it and roll it out >>> >>> I'm favouring b), particularly since this would help several different >>> architectures with a variety of issues. If we need to better document >>> that and have a process fine, but that is not a good argument for not >>> doing it at all. >> >> I agree on that, put previous efforts in the yocto universe were >> rushed through (like the machine-name -> machine_name change I keep >> going on about), so I have a knee jerk reaction to such things >> nowadays. For various reasons yocto and later oe-core have not been >> friendly to distros having package feeds out there. Sometimes the >> changes made things better, but they were still painfull. It seems to >> be getting better nowadays, which is good, but everyone still needs to >> be carefull. Pet peeve: missing PR bumps. > > Well, I think everyone is trying to improve, trying to do better and > hopefully we are learning from any mistakes made. > >> What I need for angstrom is a variable that:For >> >> 1) *never* changes its value > > As I've mentioned several times, I think it is reasonable to allarch to > clear or otherwise invalidate such a variable. That is a very special > case though and setting it to "all" was perhaps a poor choice of value.
>> 2) holds the base arch (armv7a, ppc603e, etc) > > Sounds like BASE_PACKAGE_ARCH > >> 3) Is set in *all* the tune include files > > Again sounds like BASE_PACKAGE_ARCH. Can it not default to TARGET_ARCH? Defaulting to TARGET_ARCH would break 4) > Grepping the tune files in OE-Core we seem to be pretty good about this > right now. In OE-core yes, not sure about the other layers. >> 4) must be set to complete parsing when MACHINE is set > > I suspect this doesn't give as much value as you'd think but I'm > indifferent. It's an early warning system :) _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
