Re: Sharing a source repository

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2016-01-12 at 09:36 +0000, Chris Trobridge wrote:
> I have a source (git) repository that can build a number of targets
> that could usefully be distributed across a number of recipes to be
> applied in different circumstances.  Is there a preferred method to
> allow multiple recipes to reference the same source without it being
> unpacked etc separately for each recipe (I've not seen evidence of
> any optimisation for this by default?)
> 
> To some extent this situation can be accommodated by producing
> multiple packages from one recipe.  This isn't great, or modular but
> might be mitigated a bit with includes etc.
> 
> I could move specific source to specific recipe folders and version
> control it with the meta data but that would place it outside the
> original repository and break the meta data separation.
> 
> The most promising choice so far is the "subpath" option to the git
> fetcher.  This would appear to let me pick out portions of the
> repository into different recipes that could then be rdepended upon
> (there is one 'project' within the repository that is several GB). 
>  (There are also git sub-projects but I'm not using that.)
> 
> Would using "subpath" be the preferred method for my case?
> 
> Or is there an idiomatic way to pull in a repository in one recipe
> and then reference that from other recipes?  I can think of something
> that would work but would probably be breaking the spirit (eg sym
> -linking the git directory somewhere commonly accessible to the other
> recipes).  This would also have the disadvantage of pulling the whole
> repository in even only small part was actually required.

You could look at what we do with gcc and the gcc-source recipe. Its
works there but its not common place and requires workarounds in some
corner cases like the sstate checksum debugging code.

Cheers,

Richard