Bug 15010 - native.bbclass is unable to clear unconditional overrides during dependency rewriting
Summary: native.bbclass is unable to clear unconditional overrides during dependency r...
Status: RESOLVED FIXED
Alias: None
Product: BitBake
Classification: Build System, Metadata & Runtime
Component: bitbake (show other bugs)
Version: unspecified
Hardware: All Multiple
: Medium+ normal
Target Milestone: 4.2 M4
Assignee: Richard Purdie
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2023-01-18 11:17 UTC by Enrico Jorns
Modified: 2023-03-07 12:25 UTC (History)
5 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Enrico Jorns 2023-01-18 11:17:37 UTC
When using

  DEPENDS:append = " something"

in a recipe that uses BBCLASSEXTED += "native", the generated DEPENDS list (after parsing the -native variant) will contain both "something-native" as well as "something".

(The latter is then an unexpected target dependency in a -native recipe.)

What should happen instead is that the override (:append) gets cleared during `map_dependencies()` of native.bbclass. Instead, it is applied twice (once during native mapping, and again at the finalization of DEPENDS).

That the appends are not cleared is caused by 

   d.setVar(varname, " ".join(newdeps), parsing=True)

being called with 'parsing=True' introduced by https://git.yoctoproject.org/poky/commit/meta/classes/native.bbclass?id=c4257ed8b1040a5a0e9a95846d81961741239116.

While not clearing overrides is valid for *conditional* overrides, it is not for *unconditional* ones.

However, at the moment there is no bitbake API allowing us to differentiate this.

One possible solution to this mentioned by RP in #yocto is implementing 'filters' as proposed by JPEW: https://git.yoctoproject.org/poky-contrib/log/?h=jpew/bb-filters
Comment 1 Richard Purdie 2023-01-20 12:50:12 UTC
I made some tests and it looks like for whatever reason we can now remove the parsing=True. I'll send a patch. Ultimately it would be better to switch to some filtering mechanism but that is for another day.