[yocto] Transitioning to Yocto, some basic questions about workflow

Michael Habibi mikehabibi at gmail.com
Tue Nov 10 14:27:49 PST 2015


All,



First I appreciate taking the time to read through this email. I have spent
the last couple weeks reading through Yocto/bitbake documentation, and have
run a couple of the reference builds, e.g. core-image-minimal. I have a
better-than-vague sense now of how it’s parsing confs/recipes/classes and
putting that together.


My understanding is that Yocto is nothing more than a reference build that
combines OE and BitBake to give us a good starting point for a custom
distribution. Hopefully that assumption is correct.


Our current build distribution at work is a monstrosity. We use a
proprietary distribution that combines their utilities that they provide,
along with various other open source utilities and the linux kernel.
Overall our source tree is on the order of several gig in size, with a
couple hundred build components. The build framework is close to buildroot
in that we just iterate through directories, build the applications (in
some cases it's source, in other cases it's a patched tarball), and build
up a root filesystem image that we install on the embedded target. We have
many challenges with this, namely with dependencies and build efficiencies
- we can't run parallel builds because the way it iterates through the
makefiles is not dependency-based, but directory-based.


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.


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?


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?


Thanks again for all your help, and let me know if I can help clarify
anything,


Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20151110/580eece6/attachment.html>


More information about the yocto mailing list