[oe] development process

[Denys Dmytriyenko]

On Thu, Jun 04, 2009 at 09:35:36PM +0000, Michael Sundius wrote:
> I have two issues with open embedded that I'm wondering if there is already a
> solution for, or rather, am I totally missing the boat on how things work:
> 
> 1) regarding toolchains:
> my understanding is that if you don't want to go through the exercise of
> building gcc and glibc everytime you create a distribution, then you should use
> the meta-toolchain.bb recipe to create a installable (tools) distribution and
> then others can install the resultant on their own machine and use the
> external-toolchain.bb recipe to integrate it w/ OE, populating the staging area
> and creating the appropriate packages and what not. (part a: is this correct?)

That is pretty much correct.

> what if the boss says you gotta use the xyz toolchain from blowco inc (that
> while complete, was not built w/ OE in mind and does not work w/ the
> external-toolchain.bb recipe). I'm sure someone asked this question before, but

Yep, I went through this before. You may check http://arago-project.org if you 
are interested, where I have it set up to use pre-built CodeSourcery Lite 
toolchain.

> is the only recourse to package up the libraries (ala write a recipe) yourself

I had to package the necessary libraries and provide them as a tarball.

> and put them in to oe? is there an example recipe in the openembedded tree that
> does this already? does someone have an example that they could share?, is there

My process of packaging the libraries is still very hacky and the recipe to do 
it automatically is buggy and not finished...

If you do it yourself before I find some time to finish mine, please share. :)

> a doc explaining what needs to go where? (or of course am I just off base on my
> question). could someone please educate me on best way to proceed (ie. the path
> or least resistance).
> 
> 2) in a more general sense. 
> as with most embedded systems, a developer working on a single component rarely
> cares (or knows) about how to build/configure the rest of the systems. it should
> just work. further when I have a task to fix a bug in said version of my small
> little corner of the world I don't want to wait hours for the rest of the
> software to be built before I can test my fix. is there a way to indicate my
> PREFERRED_PROVIDER for a package/recipe (or even better all by default) is a
> package feed? again maybe this is done on a regular basis or maybe its a special
> thing, but I really didn't see any documentation/examples for it. It seems the
> only reference to a package feed is to allow for easy installation of a system
> that is already up and running... 

There was a "freeze" patch few weeks ago from Chris, which generates 
versions.txt with necessary PREFERRED_VERSION lines for all the packages 
built. That file can then be included to lock the versions down. I tried this 
and it worked for me for the most part.

Later on Koen merged in a different "lockdown" implementation. For that you'd 
need to inherit lockdown class. I haven't tried this one yet though.

-- 
Denys