| Message ID | 20251219223620.2222861-1-JPEWhacker@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [bitbake-devel,v2] cookerdata: Include "originating" recipe name when parsing | expand |
On Fri, 2025-12-19 at 15:36 -0700, Joshua Watt via lists.openembedded.org wrote: > When a bbappend file is parsed, the FILE variable is set to the name of > the actual file being parsed (e.g. the name of the bbappend). Since > PN/PV etc. are derived from FILE, this means that they can be > misleading in the event that bbappend is using wildcards (e.g. PV might > have the value of "%" instead of the actual version number). > > In order to allow bbappends to derived the actual information of the > recipe, capture the name of the original recipe being parsed as > ORIG_FILE when parsing a new recipe. > > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> > --- > lib/bb/cookerdata.py | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/lib/bb/cookerdata.py b/lib/bb/cookerdata.py > index 22ac95eac..fe41bb3bf 100644 > --- a/lib/bb/cookerdata.py > +++ b/lib/bb/cookerdata.py > @@ -512,6 +512,8 @@ class CookerDataBuilder(object): > bb_data.setVar("__BBMULTICONFIG", mc) > bb_data.setVar("FILE_LAYERNAME", layername) > > + bb_data.setVar("ORIG_FILE", bbfile) > + > bbfile_loc = os.path.abspath(os.path.dirname(bbfile)) > bb.parse.cached_mtime_noerror(bbfile_loc) We discussed this a bit on the review call today, I appreciate Joshua wasn't there but it made sense to try and unblock this. In brief, the concerns mentioned were: * no tests/docs * not wanting to encourage wide use of this (conflicting with the above) * whether the name is right The idea of using a __ prefix for the variable was mentioned. That would allow Joshua to address the issues he has but not make it 'official' recommended API. That might be the compromise we need. For the name itself, I'm really torn. For variables which bitbake itself responds to, I've tried to standardise on a BB_ prefix. This is more a variable bitbake exposes for use elsewhere and we have the FILE_ prefix already being used but I'm torn on whether we should continue that theme or use something with BB_... Cheers, Richard
On Thu, Feb 19, 2026 at 9:32 AM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Fri, 2025-12-19 at 15:36 -0700, Joshua Watt via lists.openembedded.org wrote: > > When a bbappend file is parsed, the FILE variable is set to the name of > > the actual file being parsed (e.g. the name of the bbappend). Since > > PN/PV etc. are derived from FILE, this means that they can be > > misleading in the event that bbappend is using wildcards (e.g. PV might > > have the value of "%" instead of the actual version number). > > > > In order to allow bbappends to derived the actual information of the > > recipe, capture the name of the original recipe being parsed as > > ORIG_FILE when parsing a new recipe. > > > > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> > > --- > > lib/bb/cookerdata.py | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/lib/bb/cookerdata.py b/lib/bb/cookerdata.py > > index 22ac95eac..fe41bb3bf 100644 > > --- a/lib/bb/cookerdata.py > > +++ b/lib/bb/cookerdata.py > > @@ -512,6 +512,8 @@ class CookerDataBuilder(object): > > bb_data.setVar("__BBMULTICONFIG", mc) > > bb_data.setVar("FILE_LAYERNAME", layername) > > > > + bb_data.setVar("ORIG_FILE", bbfile) > > + > > bbfile_loc = os.path.abspath(os.path.dirname(bbfile)) > > bb.parse.cached_mtime_noerror(bbfile_loc) > > We discussed this a bit on the review call today, I appreciate Joshua > wasn't there but it made sense to try and unblock this. > > In brief, the concerns mentioned were: > > * no tests/docs A test should be pretty easy to do, I'll see if I can write one up; I can try to write some docs also. > * not wanting to encourage wide use of this > (conflicting with the above) > * whether the name is right > > The idea of using a __ prefix for the variable was mentioned. That > would allow Joshua to address the issues he has but not make it > 'official' recommended API. That might be the compromise we need. > > For the name itself, I'm really torn. For variables which bitbake > itself responds to, I've tried to standardise on a BB_ prefix. This is > more a variable bitbake exposes for use elsewhere and we have the FILE_ > prefix already being used but I'm torn on whether we should continue > that theme or use something with BB_... BB_ORIG_FILE then? I'd probably avoid the __BB prefix since that is reserved for variables which bitbake used internally (only). Alternatively, if we want to set a new convention of "hidden" variables, we could perhaps to do something like "bb_ORIG_FILE", but that is kinda hard on the eyes :) > > Cheers, > > Richard > > > > > > > > >
On Thu, 2026-02-19 at 09:39 -0700, Joshua Watt wrote: > On Thu, Feb 19, 2026 at 9:32 AM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > > > On Fri, 2025-12-19 at 15:36 -0700, Joshua Watt via lists.openembedded.org wrote: > > > When a bbappend file is parsed, the FILE variable is set to the name of > > > the actual file being parsed (e.g. the name of the bbappend). Since > > > PN/PV etc. are derived from FILE, this means that they can be > > > misleading in the event that bbappend is using wildcards (e.g. PV might > > > have the value of "%" instead of the actual version number). > > > > > > In order to allow bbappends to derived the actual information of the > > > recipe, capture the name of the original recipe being parsed as > > > ORIG_FILE when parsing a new recipe. > > > > > > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> > > > --- > > > lib/bb/cookerdata.py | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/lib/bb/cookerdata.py b/lib/bb/cookerdata.py > > > index 22ac95eac..fe41bb3bf 100644 > > > --- a/lib/bb/cookerdata.py > > > +++ b/lib/bb/cookerdata.py > > > @@ -512,6 +512,8 @@ class CookerDataBuilder(object): > > > bb_data.setVar("__BBMULTICONFIG", mc) > > > bb_data.setVar("FILE_LAYERNAME", layername) > > > > > > + bb_data.setVar("ORIG_FILE", bbfile) > > > + > > > bbfile_loc = os.path.abspath(os.path.dirname(bbfile)) > > > bb.parse.cached_mtime_noerror(bbfile_loc) > > > > We discussed this a bit on the review call today, I appreciate Joshua > > wasn't there but it made sense to try and unblock this. > > > > In brief, the concerns mentioned were: > > > > * no tests/docs > > A test should be pretty easy to do, I'll see if I can write one up; I > can try to write some docs also. Right, those are straightforward in many ways but it also establishes official API which is a concern. That isn't what is holding this up. > > > * not wanting to encourage wide use of this > > (conflicting with the above) > > * whether the name is right > > > > The idea of using a __ prefix for the variable was mentioned. That > > would allow Joshua to address the issues he has but not make it > > 'official' recommended API. That might be the compromise we need. > > > > For the name itself, I'm really torn. For variables which bitbake > > itself responds to, I've tried to standardise on a BB_ prefix. This is > > more a variable bitbake exposes for use elsewhere and we have the FILE_ > > prefix already being used but I'm torn on whether we should continue > > that theme or use something with BB_... > > BB_ORIG_FILE then? I'd probably avoid the __BB prefix since that is > reserved for variables which bitbake used internally (only). Someone did mention "recipe" instead of "file" might be an idea so more like BB_RECIPE_FILE maybe? > Alternatively, if we want to set a new convention of "hidden" > variables, we could perhaps to do something like "bb_ORIG_FILE", but > that is kinda hard on the eyes :) I want to try and unblock you, yet at the same time discourage people from using this. '__' is the best chance of that we have. I really don't want to do bb_ as that is horrible on the eyes. Part of me realises it is completely futile to even try and do that and thinks I may as well not try. I think the horrors people could implement with this are problematic but I really am not sure we have many other good choices. Layer specific dangling bbappend controls aren't particularly nice either. Cheers, Richard
On Thu, Feb 19, 2026 at 9:55 AM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Thu, 2026-02-19 at 09:39 -0700, Joshua Watt wrote: > > On Thu, Feb 19, 2026 at 9:32 AM Richard Purdie > > <richard.purdie@linuxfoundation.org> wrote: > > > > > > On Fri, 2025-12-19 at 15:36 -0700, Joshua Watt via lists.openembedded.org wrote: > > > > When a bbappend file is parsed, the FILE variable is set to the name of > > > > the actual file being parsed (e.g. the name of the bbappend). Since > > > > PN/PV etc. are derived from FILE, this means that they can be > > > > misleading in the event that bbappend is using wildcards (e.g. PV might > > > > have the value of "%" instead of the actual version number). > > > > > > > > In order to allow bbappends to derived the actual information of the > > > > recipe, capture the name of the original recipe being parsed as > > > > ORIG_FILE when parsing a new recipe. > > > > > > > > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> > > > > --- > > > > lib/bb/cookerdata.py | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > diff --git a/lib/bb/cookerdata.py b/lib/bb/cookerdata.py > > > > index 22ac95eac..fe41bb3bf 100644 > > > > --- a/lib/bb/cookerdata.py > > > > +++ b/lib/bb/cookerdata.py > > > > @@ -512,6 +512,8 @@ class CookerDataBuilder(object): > > > > bb_data.setVar("__BBMULTICONFIG", mc) > > > > bb_data.setVar("FILE_LAYERNAME", layername) > > > > > > > > + bb_data.setVar("ORIG_FILE", bbfile) > > > > + > > > > bbfile_loc = os.path.abspath(os.path.dirname(bbfile)) > > > > bb.parse.cached_mtime_noerror(bbfile_loc) > > > > > > We discussed this a bit on the review call today, I appreciate Joshua > > > wasn't there but it made sense to try and unblock this. > > > > > > In brief, the concerns mentioned were: > > > > > > * no tests/docs > > > > A test should be pretty easy to do, I'll see if I can write one up; I > > can try to write some docs also. > > Right, those are straightforward in many ways but it also establishes > official API which is a concern. That isn't what is holding this up. > > > > > > * not wanting to encourage wide use of this > > > (conflicting with the above) > > > * whether the name is right > > > > > > The idea of using a __ prefix for the variable was mentioned. That > > > would allow Joshua to address the issues he has but not make it > > > 'official' recommended API. That might be the compromise we need. > > > > > > For the name itself, I'm really torn. For variables which bitbake > > > itself responds to, I've tried to standardise on a BB_ prefix. This is > > > more a variable bitbake exposes for use elsewhere and we have the FILE_ > > > prefix already being used but I'm torn on whether we should continue > > > that theme or use something with BB_... > > > > BB_ORIG_FILE then? I'd probably avoid the __BB prefix since that is > > reserved for variables which bitbake used internally (only). > > Someone did mention "recipe" instead of "file" might be an idea so more > like BB_RECIPE_FILE maybe? > > > Alternatively, if we want to set a new convention of "hidden" > > variables, we could perhaps to do something like "bb_ORIG_FILE", but > > that is kinda hard on the eyes :) > > I want to try and unblock you, yet at the same time discourage people > from using this. '__' is the best chance of that we have. I really > don't want to do bb_ as that is horrible on the eyes. Part of me > realises it is completely futile to even try and do that and thinks I > may as well not try. Fair enough. __BB_RECIPE_FILE works for me > > I think the horrors people could implement with this are problematic > but I really am not sure we have many other good choices. Layer > specific dangling bbappend controls aren't particularly nice either. > > Cheers, > > Richard > > >
diff --git a/lib/bb/cookerdata.py b/lib/bb/cookerdata.py index 22ac95eac..fe41bb3bf 100644 --- a/lib/bb/cookerdata.py +++ b/lib/bb/cookerdata.py @@ -512,6 +512,8 @@ class CookerDataBuilder(object): bb_data.setVar("__BBMULTICONFIG", mc) bb_data.setVar("FILE_LAYERNAME", layername) + bb_data.setVar("ORIG_FILE", bbfile) + bbfile_loc = os.path.abspath(os.path.dirname(bbfile)) bb.parse.cached_mtime_noerror(bbfile_loc)
When a bbappend file is parsed, the FILE variable is set to the name of the actual file being parsed (e.g. the name of the bbappend). Since PN/PV etc. are derived from FILE, this means that they can be misleading in the event that bbappend is using wildcards (e.g. PV might have the value of "%" instead of the actual version number). In order to allow bbappends to derived the actual information of the recipe, capture the name of the original recipe being parsed as ORIG_FILE when parsing a new recipe. Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> --- lib/bb/cookerdata.py | 2 ++ 1 file changed, 2 insertions(+)