On 13-11-07 11:28 AM, Darren Hart wrote:
On Thu, 2013-11-07 at 08:58 -0500, Bruce Ashfield wrote:
On 13-11-07 02:22 AM, Darren Hart wrote:
BUT! AHA. Some git branch --contains on the commits listed in the output
above reveal that "standard/minnow" HEAD is v3.10.10. Now, it is
supposed to be using standard/base, but I think I've seen this before,
if the tools try to create a branch that already exists, they just use
the existing one.
Delete standard/minnow from the publish tree... and vwhalla... no more
resetting to an older tree.
So.... some kind of 'bbwarn "Hey dummy, this branch already exists"' is
in order. Digging in to see if I can find where and include it in my
instrumentation patches.
But typically, that is an expected / good thing :) If you are working
from a tree with an existing git branch, that's the content you want
to use.
Fundamentally you work from branches as a human, and that's what the
tools want to do .. let you work from the content you put in place.
SRCREVs are fine for a build system .. but as we all know, by
themselves they aren't something we can grab onto and remember. Hence
why branches (iterative development) is balanced with SRCREV processing.
The tools will already indicate if you are re-using a branch, but since
things are no longer verbosely put to the build screen, you'd have to
hunt that up from a build log.
But it didn't. This change to standard/minnow happened in patchme as
part of the do_patch task and there is next to nothing written to the
log.do_patch. There is quite a bit of improvement to be done in terms of
how logging interacts with bitbake - I have the start of a logging
mechanisms similar to bitbake (but not dependent on it) which I'd like
to be able to pass in debug level to from bitbake which would also allow
it to be used from the command line.
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.
SRCREV does matter, and right now it only works in the opposite order that
you were hitting ..if you branch is newer than the SRCREV, it is reset.
If it isn't as far along, you get what is on the branch.
Open a bug and I'll make that other case be handled in 1.6.
OK, but I'm not quite sure what the nature of the bug is yet.
So the scenario is this.
KBRANCH is standard/base
The BSP for minnow-standard.scc does:
include ktypes/standard
branch minnow
There is some ambiguity in semantics of the branch command.
From the kernel-dev manual:
Notice the branch fri2 command, which creates a
machine-specific branch into which source changes are applied.
But also:
Another method is to use the branch command in the BSP
description:
mybsp.scc:
...
branch mynewbranch
So, there appear to be two uses of the same command:
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.
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-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
