On Thu, 2013-11-07 at 11:54 -0500, Bruce Ashfield wrote: > On 13-11-07 11:28 AM, Darren Hart wrote:
> > But, other than a bunch of hashes and control characters, very little is > > written to do_patch around the the code that changes branches. > > I've removed that for the verbose logging in the latest set of updates, > or to be precise, a V=1 type logging that drops the spinner and shows > you everything that happens in behind. With that, you'll see the > existing logs that say branch <foo> (reuse), when reusing a branch. Are these pending updates or something I already have access to? > > So, there appear to be two uses of the same command: [branch] > > > > > > 1) Create a branch from the current HEAD on which to apply additional > > features (merges,patches,etc). > > > > 2) Checkout an existing branch, and then do the patches/merges > > I wouldn't call those different uses, it is always: > > - create branch from current position, re-use if there > - do more work. > > Trust me on this, we cannot error if the branch already exists. Each and > every time you build what is described in the meta data is validated > against the tree, so it absolutely expects and deals with being run many > times on the same tree. I think I get that part, and I'm not saying we have to call this an error. What I'm trying to address is how to close the gap in intention versus execution. We've actually discussed the impotency of the recipe-space KBRANCH before, and it's still a problem we need to address. This may just be a documentation issue in the end, but I think we could narrow the semantic gap with the tooling as well. For example: 1) What does it mean to specify KBRANCH=/standard/base ? I think the typical BSP author's expectation would be that standard/base would be used as the base for the kernel build. Any patches or features would merged on top of that. The reality is that any branch command in the linux-yocto meta-data could render it completely ineffectual - or not, depending on whether or not the target branch already exists or not. We can certainly improve this. 2) What is the outside-of-bitbake equivalent of KBRANCH? We should be adding some documentation on how to work with the kernel tools outside of bitbake. Right now that is shrouded in tribal knowledge which understandably widens the semantic gap. -- Darren > > Bruce > > > > > In general, the problem for me is that branch implies checkout. THe > > instrumentation problem comes in that we are executing a generated file, > > rather than marching through it, which make instrumenting it cumbersome. > > Perhaps there is a good way, to put some print statements and if this > > then bail out with a horrible message code in the generated code, but > > the tooling is generic enough as make this difficult. I'll comment on > > this more in your other response after I drive in... > > > -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel _______________________________________________ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto