On Tue, 2019-12-03 at 17:04 +1300, Paul Eggleton wrote: > Taking just this part of the discussion for now (since it is a small > familiar aspect to me) > > On Tuesday, 3 December 2019 1:08:54 PM NZDT Mark Hatle wrote: > > > You may want to consider this now. Adding system with the > > > "nomachine" > > > mode you mention is a nightmare scenario for parsing. Bitbake has > > > a > > > problem with knowing when to parse or not to parse since to > > > 'skip' > > > parsing a recipe, it needs to parse enough to know it should skip > > > it. > > > COMPATIBLE_MACHINE is implemented with the skip mechanism for > > > example. > > > If parsing is a concern (and I agree it is), you could probably > > > get > > > much further with a BBMASK approach to just the system-images > > > recipe as > > > then bitbake would know what it needs to parse without needing to > > > read > > > the recipes. > > > > The problem I have with BBMASK is that when a user tries to do > > something with > > it, they don't get a reasonable error message. > > > > For instance if I BBMASK out bash, and the user does bitbake bash > > they get an > > error. Instead of a 'bash is unavailable because ...'. > > The only practical way for that to work is the existing skip > mechanism, since PN isn't always completely defined by the .bb > filename, we need to actually parse to determine its value. gcc-cross > and other parts of the toolchain are examples. > > BBMASK is such a usability pain - both in your scenario but also in > the reverse where you have to hack it until it only masks exactly > what you do want masked - that I think we would be best advised not > to make any more use of it than we currently do, especially if it's > only to save a bit of time parsing.
If we don't like BBMASK (and I can see why), setting BBFILES to a restricted path for that config could also work. On a related note, should we improve the logging around BBMASK? There is a lot of useless output in the debug messages we should remove but that could be a good one to add... Cheers, Richard _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
