On 13-11-07 01:13 PM, Darren Hart wrote:
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?
Pending. They were too late for yocto 1.5. I broke things this week, but
I'll have them cleaned up soon.
You can enable it yourself in patchme by adding a second -v to:
kgit-meta -v --continue --apply $meta_series
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.
It means that the branch will be built, or an error will the thrown. If
you deviate from KBRANCH_DEFAULT, it means you know what you are doing
and if that branch isn't built .. the build stops.
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.
There isn't one. If you are outside bitbake, you trust the meta data
and build where they leave the tree :) The branch specifications are
pretty much only around to keep the fetcher happy.
Cheers,
Bruce
--
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...
_______________________________________________
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
