On Wed, 2024-11-06 at 09:37 -0800, Chuck Wolber wrote: > On Wed, Nov 6, 2024 at 9:18 AM Richard Purdie > <[email protected]> wrote: > > On Wed, 2024-11-06 at 08:31 -0800, Chuck Wolber wrote: > > > On Wed, Nov 6, 2024 at 6:18 AM Richard Purdie via > > > lists.openembedded.org > > > <[email protected]> > > > wrote: > > > I'd have thought quite differently about that since "include" > > already means "include all of the stuff inside of foo.inc". > > I do not disagree, and it is how I would think of it too. But from my > vantage point, I have seen a lot of people very new to Yocto/OE make > broad assumptions about the face value of stuff that surprised me. > This feels like it would be one of them, and I worry about surprising > side effects (see below). > > > > > Also, is it safe to assume that when you say "each > > > maintainers.inc > > > file it finds", it does not actually mean full layer search, but > > > something that is path relevant: > > > > > > import os > > > for DIR in BBPATH.split(":"): > > > F = DIR + "/" + INC_FILE > > > if os.path.exists(F): > > > include F > > > > Correct, the idea is it would mimic the behaviour of the existing > > require/include statements but instead of matching one file, it > > would > > match all (hence the naming). > > > > > Sorry if this question is redundant (I feel like it might be given > what others have asked) - what about side effects like pulling in a > layer that has include_all in a fragment somewhere. Would this pull > things together in a non-obvious way almost creating a "backdoor > bbappend" effect?
There is certainly some risk here but I'm not sure we enable anything terrible that you can't already do in some way. We're not adding something which acts as a bbclass extension (something we definitely want to avoid). I did wonder about putting in some kind of variable filtering so for example maintainers.inc was only expected to set the MAINTAINERS* variables but it seemed complex and fragile. We could also tweak the yocto-check-layer script to "fail" on poor behaviours. That test will already identify cases where adding a layer changes behaviour and this addition wouldn't change that. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2068): https://lists.openembedded.org/g/openembedded-architecture/message/2068 Mute This Topic: https://lists.openembedded.org/mt/109425270/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
