* using OE efficiently for development @ 2014-01-16 23:25 Nicolas Dechesne 2014-03-06 18:32 ` Cliff Brake 0 siblings, 1 reply; 5+ messages in thread From: Nicolas Dechesne @ 2014-01-16 23:25 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: using OE efficiently for development 2014-01-16 23:25 using OE efficiently for development Nicolas Dechesne @ 2014-03-06 18:32 ` Cliff Brake 2014-03-07 8:38 ` Matthieu CRAPET 2014-03-07 15:08 ` Kevyn-Alexandre Paré 0 siblings, 2 replies; 5+ messages in thread From: Cliff Brake @ 2014-03-06 18:32 UTC (permalink / raw) To: openembedded-devel 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@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@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: using OE efficiently for development 2014-03-06 18:32 ` Cliff Brake @ 2014-03-07 8:38 ` Matthieu CRAPET 2014-03-07 15:08 ` Kevyn-Alexandre Paré 1 sibling, 0 replies; 5+ messages in thread From: Matthieu CRAPET @ 2014-03-07 8:38 UTC (permalink / raw) To: openembedded-devel@lists.openembedded.org 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@lists.openembedded.org [mailto:openembedded-devel-bounces@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@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@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: using OE efficiently for development 2014-03-06 18:32 ` Cliff Brake 2014-03-07 8:38 ` Matthieu CRAPET @ 2014-03-07 15:08 ` Kevyn-Alexandre Paré 2014-03-07 17:19 ` Philip Balister 1 sibling, 1 reply; 5+ messages in thread From: Kevyn-Alexandre Paré @ 2014-03-07 15:08 UTC (permalink / raw) To: openembedded-devel Hi Nicolas, On Thu, Mar 6, 2014 at 1:32 PM, Cliff Brake <cbrake@bec-systems.com> wrote: <snip> > > 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. > Have seen kind of the same pattern as angstrom: https://github.com/gumstix/Gumstix-YoctoProject-Repo -KA ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: using OE efficiently for development 2014-03-07 15:08 ` Kevyn-Alexandre Paré @ 2014-03-07 17:19 ` Philip Balister 0 siblings, 0 replies; 5+ messages in thread From: Philip Balister @ 2014-03-07 17:19 UTC (permalink / raw) To: openembedded-devel On 03/07/2014 10:08 AM, Kevyn-Alexandre Paré wrote: > Hi Nicolas, > > On Thu, Mar 6, 2014 at 1:32 PM, Cliff Brake <cbrake@bec-systems.com> wrote: > > <snip> > >> >> 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. >> > > Have seen kind of the same pattern as angstrom: > https://github.com/gumstix/Gumstix-YoctoProject-Repo I've also had good luck with this pattern for communicating with third party builders. Philip > > -KA > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-03-07 17:19 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-01-16 23:25 using OE efficiently for development Nicolas Dechesne 2014-03-06 18:32 ` Cliff Brake 2014-03-07 8:38 ` Matthieu CRAPET 2014-03-07 15:08 ` Kevyn-Alexandre Paré 2014-03-07 17:19 ` Philip Balister
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.