Re: How to use externalsrc with git workspace

[Cliff Brake <cliff.brake@gmail.com>]

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