Re: How to use externalsrc with git workspace

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

On 03/28/2016 06:28 PM, Richard Purdie wrote:
>> 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}.
> Did you just try nobranch=1 and leave rev to get set from SRCREV?

That will parse, but it puts the wrong git rev in the PV:

The following package gets built:

blkqcl-app-tune_1.4+gitr1+a97fcb58e6-r1.0_cortexa9hf-vfp-neon.ipk

But, the actual version of the source that gets built is
0edb656fc9a1a77d75eaa49a17586deb4c986bb1.

a97... is the version of the branch (default is master) in the workspace.

So this would work if we did not care what gitv got put in the PV.  There is
also the issue of bitbake not rebuilding the source if you change the git
version of the workspace, but the branch happens to not change.

Does no one else use externalsrc with Git?

Thanks,
Cliff