On Thu, Jan 6, 2011 at 5:45 AM, Richard Purdie <[email protected]> wrote: > On Wed, 2011-01-05 at 17:00 -0700, Chris Larson wrote: >> On Wed, Jan 5, 2011 at 4:15 PM, Enrico Scholz >> <[email protected]> wrote: >> > Chris Larson <[email protected]> writes: >> > >> >> Relatively independent fix, that IMO should go into master regardless: >> >> - For debugging output for the user, only set -x when we're doing -DD, >> >> not for -D. >> > >> > I would revert this and enable '-x' by default. Job logs are in most >> > cases very difficultly to understand without seeing the commands causing >> > the output. >> >> I agree, and have a patch here to do it, setting it just before we >> call the function, always. Any objections to that? > > When thinking about this kind of stuff, I tend to try and imagine what a > general or new user to bitbake would want or expect. > > Certainly, having the run files around doesn't seem to cause much > hardship/performance loss and does mean the user can go and figure out > what happened without rerunning what they did with bitbake debug options > set. Since that is a win for usability to the general user I think we > need to keep it. > > Personally speaking, I find the output from set -x quite verbose and > irritating at times, particularly in loops like we've had in the > meta-toolchain recipes for example. It does probably make things easier > to understand for the general user though.
I agree. I think it's likely a good thing to add for the general user. It's only a minor annoyance for the rest of us. Hmm, thinking about it, I wonder what the performance impact would be of actually *executing* our shell functions with pysh. We end up parsing the scripts with it already. That would probably give us a bit more control, and I bet we could make it so it only echos the lines we run which involve external commands, for example, rather than everything. Something to think about, given pysh really does implement the builtins and all to be able to run shell scripts. > Regarding the environment, it might be an idea to dump this to a new > separate file, env.XXX in exec_task alongside the task logfile. We could > just inject a "source env.XXX" into the run file then, making it clear > which environment was being used by the shell function. This would also > mean we can clearly see what environment python tasks are running under > too which is a question I've been asked before in reference to pseudo > usage in python functions in Poky. Previously its been impossible to > figure that out without hacking bitbake's code. This seems reasonable, particularly for the python functions, now that the exported vars go into the environment. -- 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
