On Mon, Oct 21, 2013 at 09:29:27AM +0100, Anders Darander wrote: > > > "Søren Holm" <[email protected]> wrote: > >Hello > > > >What is the best way to manage a private repo with recipes as well as > >meta-oe, > >meta-core and meta-angstrom. > > >Currently I have a private repo that has the layers attached as > >submodules. Is > >that a crazy setup or what? > > We're doing the same internally at ChargeStorm. One benefit is that we're > having our "master" repo keeping track of all the layers that we're using and > which revision of those layers. > > Other people / projects just use a shell script checking out the desired > layers. Some people combines layers into one huge repo (though I'd personally > not recommend that approach). (That'd be similar to how Poky is being > managed). > > Yet other people / projects use repo. > > It's up to what you're comfortable with in the end.
I was using Makefile to checkout correct set of layers with correct revisions for SHR before and then changed it to use layerman script very similar to script used in angstrom-setup-scripts, because layers.txt is more "declarative" and easier to update than what I had in Makefile. For webos-ports project I use the same. For webos we recently switched from repo with submodules to repository with similar script (mcf - this time in python). Mostly because repos with submodules don't work well when replicating from gerrit to github. I think that biggest advantage of solution with some script, is that layers are still standalone checkouts, which developers can use as any other project (easier to submit patches upstream etc). And the script can be more clever than git pull --rebase in repo with submodules, e.g. for jenkins builds I want to automatically update build configuration in non-interactive way (because jenkins shouldn't ever keep some local changes), but for local build I want to preserve developer's local.conf changes and e.g. extra layers added in bblayers.conf etc. -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
