I’ve been asked many times why bitbake is useful, what it’s good for, and why anyone should bother to learn how to use it. From the down-in-the-weeds perspective I see bitbake fitting into a continuum of tools that developers already use. Compilers (like gcc) are used at the file-level to turn source code into binaries. At the next level there are make and configure which tie together many source files into a portable source package. And I see bitbake at the next level up, fetching packages from the internet or a SCM, applying patches, setting configure, make, and gcc variables, and selecting which binaries are pulled from the package, as well as defining how the binaries are packaged for delivery. Bitbake provides control down into software packages, and is extensible to allow additional steps like static analysis or testing.

While bitbake is capable of managing downward into the details of a particular software package, it is also aware of other packages - make and gcc don’t manage inter-package dependencies. Package dependencies are nothing new, and tools like RPM try to handle this also. Bitbake does allow you to differentiate between build dependencies and run-time dependencies though, so your system image won’t be polluted with extra packages that are simply needed on the host to build the software.

Finally, bitbake is capable of grouping related packages together into tasks. Tasks are not packages per-se, even though they are defined as bitbake recipes. An example would be a “printer” task that depends on cups, foomatic-filters-ppds, and ghostscript-gpl. By grouping these packages together into a task, you can now set build options for that particular task all the way down into the gcc and configure level. This task can also be re-used across multiple projects if your product line needs it.

In summary, bitbake helps you build your custom Linux distribution: it is compatible with thousands of recipes from various OpenEmbedded-based distributions, it provides low-level granular control over the build and install of each package, and provides higher level package groupings so you can leverage larger functional units. Done properly, a build can simply be bitbake my-product-image.

On Tue I gave a talk at RTECC Santa Clara about a source-based approach to embedded Linux. The gist of the talk was based on a few points:

• Standardized distributions don’t provide complete solutions for embedded developers
• Embedded developers heavily customize - add/remove/modify many elements in the software stack
• Every device is unique, every software stack is a Custom Linux Distribution
• A codified (standardized, programmatic) method for defining a CLD improves efficiency
• Bitbake (the tool, not OE the distro) is a step in the right direction for such a standard

The audience was mostly senior engineers, and I saw a lot of heads nodding as I introduced the first couple of points. It’s been my experience that senior engineers usually end up building and maintaining the glue-ware infrastructure for putting together a CLD. When I got into the bitbake portion of the talk I had to clarify that I was talking about bitbake-the-tool, not bitbake-plus-openembedded-distribution. This was clarified when I showed how we do this in MVL6.

Overall there was a warm response to the notion of providing a standardized way of creating a CLD, but even separating bitbake from the OE distro requires some work. Open source hasn’t quite solved the problem yet, which is why MontaVista is trying to push bitbake as a process standard, regardless of the underlying distribution.

Last week I celebrated my 5th anniversary at MontaVista, and was telling a co-worker a story about some previous engineering experiences.

At a previous employer I was on a small engineering team responsible for producing a commercial Linux distribution. Our “build system” was 1) a guy on the East Coast and, 2) some scripts on his workstation - the workstation could never be updated or modified lest we risk breaking the build.

A large conference was coming up and we needed to demo our latest software, so we crunched to get the latest bits checked in and our build guy produced some DVD images and FedEx’d them to San Francisco. We receieved the DVDs on a Friday afternoon, only to discover that upon booting the new OS the kernel panic’d.

With less than 2 days to get the system ready to ship over to the conference, and the East Coast build guy off for two weeks of vacation, the two West Coast engineers (myself and a co-worker) spent the weekend in the office pulling apart SRPMs, manually patching sources, and doing whatever we needed to cobble together something that would boot and demonstrate the applications we had ready for the show.

The products we shipped at that company were enterprise-oriented, and so the build system was really only critical to our internal process - our customers never ripped the system apart, even though it was Linux-based and they had every right to do that. Now that I’m out of Enterprise and in Embedded, I see that customers almost always want to take our products apart and put them back together to customize for the embedded devices they’re making. IMHO, this makes a build system a basic necessity of any embedded Linux product, and I’m glad MontaVista has been able to rally around the open-source build engine
bitbake and ship it in our latest product.