[oe] using OE efficiently for development

[Matthieu CRAPET]

Hi there,

I like it! I have just a small remark:
conf/bblayers.conf should be patched according to .gitmodules file.

Regards,
Matt


-----Message d'origine-----
De : openembedded-devel-bounces at lists.openembedded.org [mailto:openembedded-devel-bounces at lists.openembedded.org] De la part de Cliff Brake
Envoyé : jeudi 6 mars 2014 19:32
À : openembedded-devel
Objet : Re: [oe] using OE efficiently for development

Hi Nicolas,

This is the template I use for most projects:

https://github.com/cbrake/oe-build

Custom parts of the system that are under heavy development (kernel, u-boot, apps) go in an externalsrc directory.

I use git submodules to manage everything, but repo would work as well.

One of my goals was to have everything in separate directories for easy grepping:

sources
downloads
build/tmp
externalsrc
...

Here is another example using repo: https://github.com/kraj/angstrom-manifest

The OE build system is complex, but is very flexible and works very well.  The flexibility of fetching sources in different ways is nice, as different parts of the system really need different tools (are they under heavy development, etc) vs forcing everything to be in git, etc.

Note sure if this helps, but may generate ideas.

Cliff

On Thu, Jan 16, 2014 at 6:25 PM, Nicolas Dechesne <nicolas.dechesne at linaro.org> wrote:
> hi there,
>
> i understand the subject is a bit weird.. i am seeking for advice or 
> best practices. how would you recommend to deploy OE in a large team 
> of devs where it is the main 'build' engine for the entire Linux 
> system which is *being developed*. e.g. the developers are the 
> 'upstream' developer, but the product/system can only be built with 
> OE.
>
> e.g. an OE build does the right thing from an 'integration'
> perspective (fetch from SCM, apply patches, cleanup workspace, ...) 
> but are there any recommendations or good practices to use OE in a 
> 'development' workflow?
>
> I am familiar with externalsrc of course, but for a very large system 
> with 100+ recipes this isn't very practical. for the project I am 
> referring the current/legacy workflow is:
>
> 1- checkout all source code required to build the entire system (repo, 
> gclient, ...)
> 2- for any development item hack anywhere in any component
> 3- use a top level 'build script'
> 4- iterate until code ready, and push to SCM
>
> Basically, that looks like Android development workflow to illustrate even more.
>
> Now, how do we plug OE in such a workflow? any experience with 
> concrete product development would be very much appreciated.
>
> My initial idea (not implemented, just an idea) was to create a conf 
> file (or a layer) that has the externalsrc definition for all the 
> recipes in the layers under development (typically all the proprietary 
> system bits). the idea is to create a workspace such as:
>
> myproduct
> |- oe
> |- upstream
>
> and in 'oe' folder put all the recipes, and in 'upstream' all the 
> source code under development (git clone, svn checkout, ...). the 
> entire workspace can be checkout with repo/gclient or anything else.
>
> the externsrc variables can point to project in 'upstream' folder such 
> that switching from 'integration' mode to 'developer' mode would 
> require to include the conf file.
>
> i am thinking that such a 'developer' pattern must be so common, that 
> they should be a good solution for it already. of course i am assuming 
> that doing (large) development in WORKDIR is not very practical, and 
> that would 'force' a large team of developers to become very familiar 
> with the inner working of OE (task, clean, rebuild, ..).
>
> any good story to share about how OE is used in such 'developer'
> workflow? if we compare to the Android workflow (no troll please!) an 
> OE workflow is more 'difficult' to grasp, i hope you see what i mean.
>
> More generally, i also curious to discuss other typical developer use 
> case, such as developing upstream using 'feature branches', ...
>
> thanks
>
> nicolas
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel at lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel