[bitbake-devel] Bitbake for native x86 project?

Trevor Woerner trevor.woerner at linaro.org
Sun Oct 13 16:03:36 UTC 2013


Hi Chris,

I don't think there's anything "wrong" with what you're proposing, but
your usage is so far outside what's intended that you'd be pretty much
on your own. I don't know that there are many people using bitbake
standalone (outside of OE/Yocto), but it would certainly be
interesting to hear of such projects.

Having OE/Yocto perform your complete build from the ground up, even
when compiling on an x86 machine for an x86 target, makes a huge
amount of sense in any scenario.

Even if there is only one developer: if your one and only build
machine dies (or needs to be replaced) and you are using OE/Yocto for
your entire build, you can easily switch to a new machine, start a new
build, and be right back where you were on the last machine. In other
words you don't have to "setup" your build machine in any way to make
sure it looks exactly like the old machine. If you are using OE/Yocto
for your entire build, it takes care of "setting up your build
environment" so your build performs the same on multiple machines.

But if you do have multiple developers, if you use OE/Yocto for the
entire build, all the developers can create the same image without
having to worry about native contamination. For example, if you didn't
want to use OE/Yocto for the entire build (and wanted everyone to use
their host environment as part of their build) then they all have to
be running the exact same version of whatever Linux distribution
you're using (so they all have the same compiler, linker, headers,
etc) and they all have to have the exact same packages installed (for
configuration). This becomes rather hard to enforce.

As another example, perhaps your x86 build and target machines are
currently 32-bit, but maybe you replace your build machine with a
64-bit machine in the future; in this case you'll need your build to
be completely self-contained (and not contaminated by the host's
environment). You will no longer be able to use your host's tools for
your build, you'll need to have something setup so that OE/Yocto
performs the entire build.

As another example. Maybe you release your product today but
development continues for the next 2 years. In this case you'll need
to make sure you "set aside" your build environment (maybe you're
lucky and this is easier to do because it's all been setup in a VM).
But if you're not using a VM and you're using a physical machine for
your build, you'll need to set aside your build machine and never
update it since you'd risk building something in the future which
links to a (for example) newer version of the C library and trying to
deploy that on your device which uses an older library version. If
you're using OE/Yocto now for your entire build then all you need to
do is continue using the current release in the future and you'll
still be able to update your build machine (new features, security
fixes, etc).

When you do move to your ARM platform you will need to compile
everything from the ground up to create your image. What OE/Yocto does
is to allow you to create your distribution. Ideally switching from
your x86 target to your ARM one would involve nothing more than
changing your MACHINE definition in your local.conf and you'll end up
with the exact same image in either case, the only difference being
one runs on x86 and the other runs on ARM. But if your x86 build isn't
using OE/Yocto completely then you'll never be quite sure what's in
that one.

Hope this helps,
    Trevor



More information about the bitbake-devel mailing list