On 03/26/2016 03:41 AM, Richard Purdie wrote:
> HEAD is a revision, not a branch and the fetcher became a bit more
> picky about that difference. Your local tree must have HEAD on some
> branch which would usually be master so setting branch=master is likely
> correct, or don't set that parameter at all? master isn't just a remote
> thing.
>
> The piece which says "use the HEAD revision" is the SRCREV =
> "${AUTOREV}" line.
>
> Cheers,
>
> Richard
>
We typically set up our projects to use git submodules, such that the top level
calls out a set of submodules which are the actively developed applications and
other bits in the system. These submodules are externalsrc trees for bitbake,
and include a bitbake recipe (bitbake recipe is embedded directly in source
code). Sometimes these submodules/externalsrc trees track branches (typically
release-xyz, or develop-xyz), but almost never master. Sometimes they may be at
a tagged version that is not at the HEAD of a branch. In the end, I want to be
able to build exactly what is in the externalsrc directory, and accurately
include the git version in the PV. Branches/tags may change at any time and I
don't want to have to edit the recipe every time this happens.
Repo might be used in a similar fashion to manage a tree of components that get
built. What we are trying to avoid is having to edit the git version in the
recipes to lock down versions for a set of components for a build -- git
submodules or repo work much better for doing this.
I tried nobranch=1;rev=HEAD, but then that conflicts with ${AUTOREV}.
The git fetcher could have an option like head=1 in the SRC_URI, that told it to
use whatever is in the git workspace, and allow AUTOREV to figure out version.
Perhaps a better approach might be to figure out a function for PV that simply
extracts the git version of ${S} -- that is really all I want. In this case, I
might even need a SRC_URI, as I'm not really fetching anything -- its already
there.
Thanks,
Cliff
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
