On Thu, Jan 6, 2011 at 7:17 AM, Richard Purdie <[email protected]> wrote: > 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? :)
Agreed. Nothing new there. There are always possibilities that crop up and need to be added to the very long backlog of things to consider. >> > 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? I can certainly do so, I probably have more time available than you do at the moment :) > 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? Last I heard, there were no issues with the builds that didn't already exist without the bitbake changes, which is promising. I haven't yet verified that the removal of the env setup bits from bb.build fixes the rootfs construction for poky builds, however. I'd like to do that before merging it, and will test that today. > 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. Assuming the rootfs issue is fixed, and assuming no other issues popped up in tom's builds since yesterday, I'd say we could go ahead and merge it tomorrow or later today after the testing. -- 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
