On 12-01-12 03:52 PM, Darren Hart wrote:
On 01/12/2012 12:39 PM, Tom Zanussi wrote:
On Fri, 2011-12-16 at 19:03 -0800, Bruce Ashfield wrote:
On 11-12-16 8:34 PM, Darren Hart wrote:
On 12/16/2011 05:22 PM, Bodke, Kishore K wrote:
With the attached Darren's kern-tools-native_git.bb file, build was success.
Thanks
Kishore.
See the patch I just sent:kern-tools: Include do_install() in bbappend
for what I believe to be the solution.
I suppose the proper solution would be to version the kern-tools-native
recipe when major things like that change, but given the nature of this
layer, I think the above patch is adequate.
That's not the solution to either problem (well, yes, it's a solution
and there's nothing inherently wrong with it, it's just covering up
the underlying issue) which is a layer dependency issue. In this case,
meta-kernel-dev tracks the master branch of poky, not any other branch
or version. And that is implicit, not explicit, hence why it got into
this tangle.
We could simply branch meta-kernel-dev and have an edison branch for
it, not modify the appends to contain something that will just break
again in the future.
But meta-kernel-dev isn't officially used by much at the moment, so
I'm not convinced that branching it is worth the trouble (but I can
be convinced otherwise). I'd rather either just remove the kern-tools
bbappend (I'm probably the only one on the planet that really needs
it), or just trust people to know what they are up to with the
meta-kernel-dev layer.
Revisiting this - meta-kernel-dev is used in the documentation, and
Scott has now run up against this when testing and updating it. Since
the documentation does use edison, and the walk-throughs have the user
check out edison branches of both poky and the BSP layers, it would be
consistent to have the user also do the same for meta-kernel-dev.
Probably just an edison branch with the kern-tools bbappend removed
would work fine...
Tom
Works for me.
Seems ok. I can create a branch shortly, once I'm slightly out from
under my 3.2 tree creation rush.
Bruce
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
