On Thu, 2011-01-06 at 06:56 -0700, Chris Larson wrote: > 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: > > 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.
Its certainly worth thinking about. Lets try and get the current round of things sorted out before we try that though? :) > > 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. Just so I understand who is doing what, are you going to have a go at these things? For the poky-sync branch, is there anything blocking merging that? I think that branch and master possibly have a conflict over the python function handling after the last commit to master which is why I haven't pulled that change into Poky yet. How did the tests you/Tom were going to run work out? If we can get that merged, we'll be in a better position to sort out the remaining bits with Poky and get us back to one codebase for bitbake. Cheers, Richard _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
