In the BitBake variables table, any files showing as part of the variable history that are inside the /bitbake directory show their full path, instead of a path relative to the checkout directory. For an example, check the history of BBFILES for any Toaster build. You will see things like /home/yocto/_poky_master.toaster_cloned/bitbake/lib/bb/cooker.py instead of /bitbake/lib/bb/cooker.py
Since I might have local, master, and jethro projects/builds going this might be more helpful than harmful in tracing where the "action" is...
(In reply to comment #1) > Since I might have local, master, and jethro projects/builds going this > might be more helpful than harmful in tracing where the "action" is... Ay, this is going to be messy :/ Yes, seeing full paths is definitely helpful if you are working locally or running your builds on a server you have access to. What I wonder is what happens when that's not the case: the case where I have a customer or a team of developers and I provide them access to the build system via a Toaster instance that runs builds in servers I administer but my "customers" cannot access. Does showing the full path to a file in this case help debugging in any way? Would that be considered "dangerous" by whomever administers the build servers? I genuinely don't have good answers to these questions, so I'll go with whatever you tell me. In any case, we should be somehow consistent. We spent quite some time removing full paths from Toaster on the assumption that they wouldn't be helpful. If that assumption is wrong (and it very well may be) we should look into the different paths we show across Toaster and decide when it is appropriate to display them in full, which is somehow connected to bug 8795 and bug 8188.
Currently, we express truncated paths for the files that are in the layers we use. This is a UI inconsistency. I'm moving it to future unassigned unless it gets more attention by causing problems in typical usage.
Reviewed 10/18