On Sat, Feb 20, 2010 at 3:58 PM, Richard Purdie <[email protected]> wrote:
> On Fri, 2010-02-19 at 18:39 -0700, Chris Larson wrote: > > On Thu, Feb 18, 2010 at 9:58 AM, Richard Purdie <[email protected]> > wrote: > > > On Thu, 2010-02-18 at 09:13 -0700, Chris Larson wrote: > > > > With COLLECTIONS (and BBLAYERS could work similarly), all the overlay > > > > priorities and bbpath ordering are automatically determined based on > the > > > > order of entries in the variable. Documented as highest-to-lowest. > > > > > > > > Note that I'm not necessarily arguing against the use of a per-layer > > > > configuration file, as this seems like it would be quite useful, but > I > > > > question the need for the boilerplate. > > > > > > Its certainly possible to put defaults in which would handle the > > > "standard" case. My main dislike is having to hardcode behaviour and > > > variable handing into bitbake in that case. > > > > Not hardcoding *any* behavior into bitbake is how we got into the mess > that > > we're in, > > In many ways, its helped make bitbake what it is IMO. Bitbake and OE > have a fairly clearly modularised structure where you can replace > individual elements and this is a major attraction of it. Yes it causes > some pain at times but it also makes many things possible too. > > > and is likely the source of a large amount of confusion on the > > part of our userbase, and is likely the cause of some of the performance > > issues as well. Flexibility is good, but there's a point at which the > > benefits no longer outweigh the drawbacks. > > The performance issues seem to stem from two things, the anonymous > methods and the way our data store works as far as I can tell. We could > do with finding a better way to handle the methods I agree but they also > have massive benefits too. > > As for confusion of the userbase, this i still more a documentation > problem. Those who really understand it don't document it. The > documentation I have written is for Poky and few people bother to read > it, even if most of it is generic :(. Starting to hardcode behaviour is > unlikely to lead to much improvement for the users IMO. > > > > The idea that adding an empty layer.conf file breaks a previously > > > working overlay seems counter intuitive too... > > > > > > > The layer itself deciding where it goes in the BBPATH is not obvious or > nice > > or clear to me the way it seems to be to you. How can a given layer > claim > > to know where it should go in the bbpath, what its priority should be? > > Think about how people are going to use layers. Its never likely that a > random collection of layers are going to work together without some > (possibly minor) effort. Layers are going to end up advertised as being > enhancements for OE, Poky or some specific choice. > > The "policy" on where in BBPATH (prepend or append) and actual priority > numbers are going to be a policy decision for those projects, just like > the bitbake.conf. > > I'm quite happy if a standard emerges. My point is that policy should > not be in bitbake if we can help it. > > > I > > think it makes a great deal more sense to let the order/information in > > bblayers.conf define that, as the user has direct control over that. Can > > you think of any cases where a given layer could possibly know better > than > > the user, or where defining the priority via BBLAYERS is insufficient? > > Regarding BBFILES, there's nothing to hardcode. Add the layer to > BBFILES, > > let bitbake find the recipes, and you have BBMASK to remove the ones you > > don't want. > > I disagree but its pointless to take this further and spoil what > otherwise is a useful patch, we'll just add the default behaviour you > describe. I see a few problems here. First, there's more to a notion of priority than just 'prepend' and 'append'. It's unlikely that a given layer will either way to override everything else, or be overridden by everything else. Second, the final resulting BBPATH will end up depending upon ordering anyway, because the prepend/appends will be applied based on the order of the parsing of the bblayer.conf files. Third, you seem to be retaining the separation between configuration file / class priority (BBPATH) and collection priority (BBFILE_COLLECTIONS, priority number). Users see a layer/overlay/collection as a single entity, not two components whose interactions with everyone else may vary. If you're going to use a priority numbering scheme or something similar, defined by the layer, then everything should obey it, in my opinion, and BBPATH_prepend/append is not sufficient to reflect that priority scheme. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
