Bug 7877

Summary: Inject comments into generated shell to aid debugging
Product: [Build System, Metadata & Runtime] BitBake Reporter: Igor Stoppa <igor.stoppa>
Component: bitbakeAssignee: Chris Laplante <mostthingsweb>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: mostthingsweb, poky.bs.watcher, poky.watcher, randy.macleod
Version: unspecified   
Target Milestone: 3.2   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know

Description Igor Stoppa 2015-06-11 09:02:14 UTC 
Precondition
------------

Recipe A containing the (wrong) fragment:

if [ i! -f filename ]; then     <--- notice the "i" before "!"
   do something
fi



Recipe B containing the (failing) fragment:

if [ ! -f filename ]; then
   install -m 0644 source dest   <--- here the source file was missing
fi


Trigger Action
--------------

Run bitbake on both A and B recipes


Expectation
-----------

In both cases bitbake should point me to the line number where the error happens.
I'm referring to the line number in the temporary script obtained with the expansion of macros/parameters


Actual Outcome
--------------

For recipe A I get the correct line number.

tmp_file_name:correct_line_number



For recipe B I get a (bogus?) line number 1

tmp_file_name:1
Comment 1 Igor Stoppa 2015-06-11 09:22:03 UTC 
Correction:

* I tried to reproduce it once more and noticed that A seems to succeed.
Replace A with:

if [[ ! -f filename ]; then     <--- notice the double, unmatched "["
   do something
fi


* B fails but it actually doesn't report any line number at all

* A, instead, shows:
"....tmp_script.16852: line 102: syntax error in conditional expression"
Comment 2 Richard Purdie 2015-12-22 09:16:59 UTC 
I've been giving this some thought. The errors you see are from the shell, and trying to get the shell to refer directly to the .bb file line numbers would be hard since the shell interpreter knows nothing of those.

Would it help here if we inject comments into the shell scripts which give an idea of which files/lines the functions themselves come from? Variable expansion and appends can still distort things a bit but this might at least start to give an idea of where the problem was from? Would you consider that a fix for this problem?
Comment 3 Igor Stoppa 2015-12-22 16:05:01 UTC 
I'm a bit reluctant to answer "is this solution good enough?" sort of questions, because I'm not the only one who would be affected.

Otoh I filed the bug, so I'll try to give a meaningful answer.
 
Especially considering that what I described is a generic problem that can happen quite frequently, in different incarnations.

What I would find useful, when developing/debugging, is to have feedback that points me to the error in a way that is both univocal and explicit.

I should be spending my time fixing the error, rather than wondering if it was caused by this or that line, from one recipe/fragment or another.

Is the solution you are proposing matching what I described?
Comment 4 Richard Purdie 2020-05-28 06:58:57 UTC 
We can improve the situation by injecting comments into the generated shell about where code originated from. This won't totally fix the problem but it will improve the situation. Going to target this bug at that specific task which gives us a way of measuring completion too.

The injected comments would indicate which file/line code had come from (and which variable?).
Comment 5 Chris Laplante 2020-09-08 08:56:23 UTC 
Both shell task comments and metadata-relative backtraces are now implemented. I think it will be in for 1.46. Should I mark it as fixed?
Comment 6 Randy MacLeod 2020-11-19 16:19:31 UTC 
Fixed according to Chris.