> I am aiming for this use case to be supported with my utility. What I would > also like to handle though is that if you have chosen to set up some > configuration, then it will be able to be read in before the fetching starts.
Sounds reasonable. >> I get it you don't want it to be automatic. Do you have something I can look >> at that addresses the remote layering? > > I've thrown together a proof-of-concept "bitbake-fetchlayers" in the > "paule/remotelayers" contrib branch: > > http://git.yoctoproject.org/cgit/cgit.cgi/poky- > contrib/log/?h=paule/remotelayers > > This is by no means a finished utility, may have hideous bugs, etc. This > requires nothing more than vanilla bitbake to operate. Some notes: > > * BBPATH needs to be set, LAYER_UNPACKDIR also. > > * Currently it requires conf/bitbake.conf, classes/ etc., which are shipped > with bitbake master but are not present with the copy of bitbake that's in > Poky; I hope to be able to address this in such a way that the utility does > not require these. > > * "init" is the command used to fetch multiple layers. I've also provided > "fetch" as a way to test a single fetch operation; I would expect the latter > to be removed at some point. (Also, none of these command names are final.) > > * Update is not yet implemented. For your use case, update is no more than a > re-fetch; however where you are intending to interact with the layers as SCM > working directories it would be better to do an update in-place. I'm still > thinking about how best to implement this. I will try and check this out later this week. > * Output is rather noisy, this needs to be fixed also. k. > * I did have to patch the fetchers as Richard suggested so they have default > values for the configurable fetch commands. (We'd have to have done this > anyway.) Great. > > I think we can support this without any issues - any of bitbake's fetchers > should be able to be used, including wget and local. You won't need to grab > oe-core first. Okay. > Hmm. For simplicity I've only supported fetch2 in bitbake-fetchlayers - in > fact it forces it at startup. It would not be hard to support fetch also, > however I hope we could avoid having to do so. That is fine. The legacy code is likely not going to be moving over to this anyways. It was more of a response to why did you do it, rather then it needs to support it. Don't bother unless it is really needed by someone else. -- Jeremy Puhlman Montavista Sofware, LLC. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
