[oe] Working with OEMs

[C Michael Sundius]

On Tue, Feb 9, 2010 at 1:47 PM, Michael Smith <msmith at cbnco.com> wrote:

> 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
>

we used just two collections:
openembedded:  a trimmed down openembedded tree with just the recipes that
we use
local: just like your "private"


> 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.
>
> this is why we only use a trimmed down version of the OE tree. our
developers would completely revolt if we had to parse all 20k recipes... I
think its really 20k...

this is easier for building, but makes it harder to sync with the main tree.


 but I'm thinking that maybe I'll just create a file with a list of the
recipes (or just the recipe dirs) that I can used to build my BBFILES list
with. That way I'll be able to keep the whole oe tree..

We do not use git here :[ we used something call Synergy CCM (I had never
heard of it before either, but I guess its a company owned by IBM... its not
very friendly) ,  anyhow there is no fetcher currently supported. I see that
we will likely need to write our own fetcher so that we can enforce
versioning better.

we've, however, really actually been very successful by creating a class
that adds a task before the patch task.. it just sets up a symlink to the
checked out version of the code... its simple and I'm sure we could do
something fancier, but it wroks really well... it just means that we need to
pair the baseline of the OE repo w/ the source code repo.

-----------------

I have not used the srctree class, though I noticed it a while back and have
not had time to check out what it is or how it works.. (Now I guess I have
to go and educate myself...). Also not aware of the amend.inc file

-----------------

we've had long discussions about how to reconsile our software versions (for
proprietery code) and the recipe versions since they don't really follow the
version - revision way of doing things that OE uses. This has been difficult
one, I'd like to push them to be better with versioning, but infact we need
to have a real fetcher for our source control software before we can enforce
which version is built by each recipe.

---------

Finally, our drivers and applications teams just condensed their nicly
modularized recipes into just two recipes because intra recipe dependency
checking was not working (i.e. when you rebuild one recipe its dependant
recipes should rerun, but don't). I finally provided them a solution but
they had already created monster recipes for all of their source code :}



> 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.
>

we use lots of magic that puts the image in a form that can be installed on
the box. this is done in the image-postprocessing function (theres a hook
for this in the image class, forget what its called). we don't really track
the individual packages.. just the image since we never allow installing
individual packages the box.

 thanks for your comments.