On Wed, Jan 5, 2011 at 11:49 AM, Michael Smith <[email protected]> wrote: > 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. > > 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.
set -x isn't default now, you're saying you'd prefer that was the case always? > 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. That's not likely to happen, as the same functions are run to do the emission, they just get emitted to two different places, but that's a good point. > 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. This is a very good point, thanks for the feedback. Perhaps this isn't worthwhile. It was just a prototype I threw together, since it seemed unnecessary to both emit variables into the environment and into the shell script we execute. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
