Randy, I've had some time to think about your post and I had a follow up question. Let's say we had internal applications, you suggest that the fetcher can be used to pull down the git/svn repos that contains the internal application code. In this environment, where is the Yocto framework hosted? Is it also on a repo? Would then we have a Yocto repo for image building, and an application repo for application development? Is there a clean way of combining both Yocto and internal applications into a single repo, so our engineers simply have to do a 'git clone' and they'll have what they need to get started?
Thanks, still trying to wrap my head around this a bit. On Tue, Nov 10, 2015 at 6:06 PM, Randy Witt <randy.e.w...@linux.intel.com> wrote: > Hi Michael, > > See my replies below. > > On 11/10/2015 02:27 PM, Michael Habibi wrote: > > >> >> This is fundamentally why I have been looking into Yocto/BB/OE as a >> potential replacement distribution. However, I have a couple questions >> stemming from my research. We can leverage the existing Yocto build for >> various open source utilities where it pulls from the web, patches, >> builds, >> and installs into the deployable image. We would probably want to colocate >> the tarballs locally, because we would like to prevent people from having >> to fetch from the web during build cycles. >> >> > This is pretty common. You can set up SOURCE_MIRROR_URL, to specify local > mirrors to try before using the upstream url in the recipe. So each person > building would at least have to fetch from the local mirror for a build, > but subsequent builds wouldn't require fetching again as long as the DL_DIR > was preserved. > > https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-SOURCE_MIRROR_URL > > https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-DL_DIR > > >> I see that Yocto thinks of the deployable image and applications as >> separate entities: first you'd build the distribution, then you would use >> ADT/cross-toolchain/etc to build the applications and install them >> separately. However, in our environment, we would need all of our custom >> IP >> applications to be built as part of the deployable image, and not as a >> separate procdure. For example, if I were to call "bitbake our-image", I >> would like the deployable image to contain 1) the kernel, 2) various core >> utilities and libraries for booting, and 3) our custom applications for >> our >> device. >> >> >> This means that somewhere in the yocto framework, we'd ideally have some >> source code somewhere that would also be compiled via recipes/classes that >> we'd have to custom write. Is there a best practice for this kind of >> workflow? I don't mind not having source checked in to our VCS for things >> like the kernel, OpenSSL, etc (those can be tarballs obtained from a local >> server), but we likely wouldn't want to host tarballs for the applications >> we are writing and modifying day-to-day by dozens of engineers. Is there a >> place where this source would best fit? Would it be under build/tmp/etc, >> or >> perhaps we can locate the source under a layer directory, like >> meta/source/our-ip-applications? >> >> > For all the internal applications at my previous employer we had a layer > for all internal items, it's quite common. > > And if you're not aware, source code is not restricted to tarballs. You > can use git repos, svn and any mechanism the fetcher supports.(even local > directories) The following URL lists the types the fetcher supports. > > https://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-SRC_URI > > The workflow now encouraged, is to use recipetool to assist in creating > recipes. And then once the recipes are created, you can use devtool to > actually do the iterative development on the application represented by the > recipe. > > https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-devtool-in-your-workflow > > >> Or perhaps this workflow is just not recommended or supported by the Yocto >> Project? If that's the case, does Yocto only recommend building the >> distribution then building the applications as completely separate >> workflows? Or is there another workflow that I haven't stumbled across >> yet? >> >> > There is nothing "wrong" with building the image each time as a developer. > However, it is time consuming to construct the full image and deploy it. > > A much more appealing mechanism would be to use devtool to build the > recipe you are working on, and then use "devtool deploy-target" to then > deploy the output to a live machine. This would require a writeable > filesystem on the target device, but if that is available, the workflow and > turnaround time is much faster. > > > >> Thanks again for all your help, and let me know if I can help clarify >> anything, >> >> >> Michael >> >> >> >> >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
