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 -- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
