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
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
