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
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"
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?
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?
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?).
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?
Fixed according to Chris.