Chris Larson wrote:
- Emit shell code into the stdin of the spawned shell process, rather
than emitting a shell script and having it run it
- Only emit functions to the shell, not variables
- Only emit run scripts for debugging purposes, not always
- For debugging output for the user, only set -x when we're doing -DD,
not for -D. So -D lets you see the output of the build, but -DD lets
you see what *we* are doing, in addition, with regard to bb.build.
Hi Chris,
Often I don't know I want debugging until after the fact, so I'd prefer
to have run scripts and "set -x" by default. Otherwise I'd have to
re-run with -DD and it'll be a pain.
Sometimes a task used to work, and doesn't anymore, or I'm tracing a
regression between two trees; in that case re-running the previous
version with -DD isn't always possible.
> - Emit shell code into the stdin of the spawned shell process, rather
> than emitting a shell script and having it run it
> - Only emit functions to the shell, not variables
I'm not entitled to an opinion about these two, but I'm leery of having
one code path for execution (export variables, then write functions to
stdin, then execute) and a separate debugging code path (write variables
and functions to a file that is not executed). Let's say down the road
someone exports something new in the execution code path and they forget
to add the equivalent statement to the debug code path. It'd be hard for
a user to figure out what's going on and report the bug.
Also, if there's a shell syntax error or wrong command name in a recipe,
the shell will report the line number from stdin; this won't match up
with the line number in the run file.
Thanks,
Mike
_______________________________________________
Bitbake-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bitbake-dev
