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. Cheers, Richard _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
