On 13-11-07 02:06 PM, Darren Hart wrote:
On Thu, 2013-11-07 at 13:45 -0500, Bruce Ashfield wrote:
On 13-11-07 01:13 PM, Darren Hart wrote:
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.
But it didn't. I specified KBRANCH=/standard/base and it build
standard/minnow, no complaints.
Check KBRANCH_DEFAULT. What's the value ? If they are the same, but
you set it .. the result is 'nil. And that's what you have. It
was the best way to detect that the user has really specified a
hard branch requirement. Otherwise, the meta-data in the kernel
is useless to get the tree to the right place.
That was supposed to be documented, I'll double check to see if that
isn't the case.
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.
Right, that is what I remembered form our discussion. KBRANCH was only
added to cooperate with SRCREVs. Unfortunately, as you said above, it
has broader, more vague impacts on the build.
I get that this is an annoyance for you ;-) but if I'm burning two days
to resolve issues like this (and I wrote the book on it - haha), we can
be sure that others will throw their hands up in the air give up long
before this point.
Agreed. And I'm happy to make more changes to make this more
obvious, I don't like opaque errors. Including figuring out a better
way to detect when the recipe author means "use my branch or die!" :)
Bruce
_______________________________________________
linux-yocto mailing list
linux-yo...@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
