Bug 9454

Summary: improve on why a recipe is built
Product: [Build System, Metadata & Runtime] BitBake Reporter: Robert Yang <liezhi.yang>
Component: bitbakeAssignee: Chen Qi <Qi.Chen>
Status: RESOLVED INVALID QA Contact: Francisco Pedraza <francisco.j.pedraza.gonzalez>
Severity: enhancement    
Priority: Medium+ CC: bluelightning, jose.perez.carranza, poky.bs.watcher, poky.watcher, randy.macleod
Version: 2.2   
Target Milestone: 2.2 M3   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: No (bug/feature does not impact docs)

Description Robert Yang 2016-04-13 00:16:23 UTC 
Sometimes, it's hard to figure out why a recipe is built, for example, without
TOOLCHAIN_NEED_CONFIGSITE_CACHE = "" in buildtools-tarball.bb, bitbake -g buildtools-tarball shows that ncures would be built, but we can't find why in the *.dot files or bitbake -DDD -g buildtools-tarball, in the log we can see:

DEBUG: providers for ncurses are: ['ncurses']

But it does says which recipes requires ncurses, and why added ncurses.

we can try to do do something to improve this.
Comment 1 Randy MacLeod 2016-04-14 15:04:06 UTC 
Robert, Can you start a discussion on the email list to explain the problem and suggest and ask for possible solutions? Richard wants this to be done early in 2.2 if the suggested solution is acceptable. M3 would be too late for a potentially intrusive change.
Comment 2 Chen Qi 2016-07-15 05:40:16 UTC 
I just did a little testing.
The result shows that we can see why ncurses is built.

chenqi@pek-hostel-deb01:~/poky/build-systemd [1] $ grep ncurses task-depends.dot | grep -v ncurses-native | grep -v nativesdk-ncurses | grep buildtools
"buildtools-tarball.do_package_write_rpm" -> "ncurses.do_package_write_rpm"
"buildtools-tarball.do_packagedata" -> "ncurses.do_packagedata"
"buildtools-tarball.do_populate_sysroot" -> "ncurses.do_populate_sysroot"
"buildtools-tarball.do_build" -> "ncurses.do_build"

Let's close this bug?
Comment 3 Paul Eggleton 2016-07-18 21:14:13 UTC 
After a discussion in triage, I think we like all the idea of this but nobody seems to know what we can actually do to improve it. Therefore I'm going to close this (using "INVALID" - that's not the right resolution but I can't see any better one). If anyone comes up with a better idea of what to do we can reopen.