Re: Working with OEMs

[Michael Smith <msmith@cbnco.com>]

C Michael Sundius wrote:
> Further, I wonder if there are others out there who also feel
> this way? My understanding is that Monta Vista is using OE; are there voices
> on this list from MV or others that use OE for creating a consistent means
> of building for developers and Config/Release Managers? If so, what are your
> tricks and complaints with respect to this issue.

Hi Mike,

I'm using COLLECTIONS, the srctree and gitver classes, plus amend.inc. I 
think all of the above come from Chris at MV. It's about three billion 
times better than the custom build system we had before.

We have four trees:

- public: playground for new recipes before submitting to OE; also, 
amend.inc's to tweak packaging behaviour or configure flags.
- private: recipes to build closed-source drivers from our suppliers;
- oe: full org.openembedded.dev;
- proj: git repos for internal projects get cloned here, and added to 
COLLECTIONS with wildcards

Building the internal projects with OE means they barely even need to be 
cross-compile aware. All they need is a simple Makefile, and a git tag 
to set the package version. It's way easier than writing a one-off build 
system for each project.

The only problem is that bitbake takes forever to start up: COLLECTIONS 
causes a re-exec of Python, I think, and there are about 8,000 recipes 
in the tree. But we get around it by passing in a specific recipe file 
with -b.

For release management, I have a class that creates a list of the .deb 
packages that would have gone into an image, and a script that checks 
them into the right place in CVS. If you use Angstrom I think you get 
the same list for free every time you build an image. The class just 
saves me from waiting for rootfs to run.

Mike