creating images which include actively developed applications

creating images which include actively developed applications

[Brian Karcz]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

Hi,

I'm attempting to create a recipe for some custom applications that we want to include in our target image. The applications are actively developed and it's often desired to generate images without versioning the application code. It's also desired to be able to work in a source tree that is external to the build tree. I'm trying to determine if Yocto has a mechanism similar to the "source directory override" in Buildroot that allows you to point a package/recipe at an external directory to locate the source code.

We have been using Poky for a couple years, but so far, have had to build the applications externally and use some magic in the image recipes to bring in the pre-built executables explicitly. We accomplished this by using some relative pathing in the SRC_URI and then placing the files in the rootfs by adding some commands to the image preprocess command.

Is there a way to create a recipe to build actively developed code located in an external source directory? Basically skip the fetch and unpack steps and always execute the compile and populate steps each time and image is built?
Thanks,
Brian



[-- Attachment #2: Type: text/html, Size: 4334 bytes --]

Re: creating images which include actively developed applications

[Paul Eggleton]

Hi Brian,

On Wednesday 22 April 2015 15:32:06 Brian Karcz wrote:
> I'm attempting to create a recipe for some custom applications that we want
> to include in our target image. The applications are actively developed and
> it's often desired to generate images without versioning the application
> code. It's also desired to be able to work in a source tree that is
> external to the build tree. I'm trying to determine if Yocto has a
> mechanism similar to the "source directory override" in Buildroot that
> allows you to point a package/recipe at an external directory to locate the
> source code.
>
> We have been using Poky for a couple years, but so far, have had to build
> the applications externally and use some magic in the image recipes to
> bring in the pre-built executables explicitly. We accomplished this by
> using some relative pathing in the SRC_URI and then placing the files in
> the rootfs by adding some commands to the image preprocess command.
> 
> Is there a way to create a recipe to build actively developed code located
> in an external source directory? Basically skip the fetch and unpack steps
> and always execute the compile and populate steps each time and image is
> built?

Indeed there is:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-software-from-an-external-source

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: creating images which include actively developed applications

[Brian Karcz]

Hi Paul,

Thanks for pointing me to that. It sounds like exactly what I need. I can't believe that I've not come across that in my searches. I suppose its a matter of using the right search criteria.

It looks like I can add those lines to either local.conf or the package recipe. Once I do that I have a couple question on how it works:

1) does the version of the recipe become moot? Does it still need dummy versions in PV and PR to be valid?
2) can the SRC_URI now be omitted in the recipe since there is nothing to fetch?
3) can the "S" variable be used to drive into the source tree to find the applications top level makefile or should I just point the EXTERNALSRC variable right there and it will be fine navigating above that base?
4) can the recipe still inherit autotools to perform the build on the external source directory?

I'm now envisioning a package recipe that looks something like:

PV = "1.0"
PR = "r1"
DESCRIPTION = "abc package located outside build tree"
INHERIT += "externalsrc"
EXTERNALSRC_abc = "../../../../../abc"
S = "../../../../../abc/apps/build"
inherit autotools

Its propably unlikely, since this lends itself to being very custom, but do you know of any examples of a recipe implementation that use this mechanism?

Thanks,
Brian

-----Original Message-----
From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com] 
Sent: Wednesday, April 22, 2015 1:58 PM
To: Brian Karcz
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] creating images which include actively developed applications

Hi Brian,

On Wednesday 22 April 2015 15:32:06 Brian Karcz wrote:
> I'm attempting to create a recipe for some custom applications that we 
> want to include in our target image. The applications are actively 
> developed and it's often desired to generate images without versioning 
> the application code. It's also desired to be able to work in a source 
> tree that is external to the build tree. I'm trying to determine if 
> Yocto has a mechanism similar to the "source directory override" in 
> Buildroot that allows you to point a package/recipe at an external 
> directory to locate the source code.
>
> We have been using Poky for a couple years, but so far, have had to 
> build the applications externally and use some magic in the image 
> recipes to bring in the pre-built executables explicitly. We 
> accomplished this by using some relative pathing in the SRC_URI and 
> then placing the files in the rootfs by adding some commands to the image preprocess command.
> 
> Is there a way to create a recipe to build actively developed code 
> located in an external source directory? Basically skip the fetch and 
> unpack steps and always execute the compile and populate steps each 
> time and image is built?

Indeed there is:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-software-from-an-external-source

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: creating images which include actively developed applications

[Paul Eggleton]

On Wednesday 22 April 2015 20:51:08 Brian Karcz wrote:
> Thanks for pointing me to that. It sounds like exactly what I need. I can't
> believe that I've not come across that in my searches. I suppose its a
> matter of using the right search criteria.

So I do want to mention one thing - we envisaged externalsrc more for 
situations where you temporarily want to build from an external source tree 
(for example, when you're in the middle of development). The expectation is 
that when you reach production you switch over to a standard repository 
specified in SRC_URI. Having said that there aren't any actual barriers to 
using it on a more permanent basis as it sounds like you may  be considering 
(although perhaps I've misunderstood.)

> It looks like I can add those lines to either local.conf or the package
> recipe. Once I do that I have a couple question on how it works:
> 
> 1) does the version of the recipe become moot? Does it still need dummy
> versions in PV and PR to be valid? 

There isn't a requirement for PR/PV to be set whether you use externalsrc or 
not - if you don't specify these there are defaults. PV is typically specified 
through the file name (after the underscore) and PR generally doesn't need to 
be set or incremented manually these days with the advent of the PR service.

> 2) can the SRC_URI now be omitted in the recipe since there is nothing to
> fetch? 

You can leave it completely blank if you wish. In dizzy and earlier, SRC_URI 
is effectively ignored with externalsrc. In master and the just-released fido 
release, any local file:// references will still be fetched if present, remote 
URIs will be ignored.

> 3) can the "S" variable be used to drive into the source tree to find the
> applications top level makefile or should I just point the EXTERNALSRC
> variable right there and it will be fine navigating above that base? 4) can
> the recipe still inherit autotools to perform the build on the external
> source directory?

S is no longer used when externalsrc is enabled for a recipe; EXTERNALSRC 
should point to the base of where the source is (i.e. where S might have 
pointed to in the unpacked source tree  were you not using externalsrc).
 
> I'm now envisioning a package recipe that looks something like:
> 
> PV = "1.0"
> PR = "r1"

You shouldn't need these.

> DESCRIPTION = "abc package located outside build tree"
> INHERIT += "externalsrc"

INHERIT += is for conf files, in a recipe you need to use inherit instead.

> EXTERNALSRC_abc = "../../../../../abc"

I don't think a relative path will work, or at least if by some chance it does 
work I would still advise using an absolute path.

You don't need an override (_abc) here - well, unless your recipe uses 
BBCLASSEXTEND and you only want to apply to one of the variants, that is. 
There's one given in the example in the manual because there it is talking 
about setting it from a conf file rather than within the recipe, thus you need 
to set an override to make it applicable only to the desired recipe.

> S = "../../../../../abc/apps/build"

You can drop S.

> inherit autotools
> 
> Its propably unlikely, since this lends itself to being very custom, but do
> you know of any examples of a recipe implementation that use this
> mechanism?

No, there won't be any I'm afraid as typically this is used as a temporary 
measure.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: creating images which include actively developed applications

[Khem Raj]

Paul

> On Apr 22, 2015, at 4:22 PM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> 
> On Wednesday 22 April 2015 20:51:08 Brian Karcz wrote:
>> Thanks for pointing me to that. It sounds like exactly what I need. I can't
>> believe that I've not come across that in my searches. I suppose its a
>> matter of using the right search criteria.
> 
> So I do want to mention one thing - we envisaged externalsrc more for 
> situations where you temporarily want to build from an external source tree 
> (for example, when you're in the middle of development). The expectation is 
> that when you reach production you switch over to a standard repository 
> specified in SRC_URI. Having said that there aren't any actual barriers to 
> using it on a more permanent basis as it sounds like you may  be considering 
> (although perhaps I've misunderstood.)

Application development doesn’t end is what really happens, so developers will need to keep
using something like this forever on a given application, and somehow externalsrc sounds
temporary i.e. not included into regular workflow.

> 
>> 2) can the SRC_URI now be omitted in the recipe since there is nothing to
>> fetch? 
> 
> You can leave it completely blank if you wish. In dizzy and earlier, SRC_URI 
> is effectively ignored with externalsrc. In master and the just-released fido 
> release, any local file:// references will still be fetched if present, remote 
> URIs will be ignored.

Will they be just fetched or also applied to source tree like in non-externalsrc case.
getting a  'prepared source tree' in an externalsrc env is a big confusion point for developers
where a given component is building totally fine and if one want to use externalsrc then developer
needs to do ‘preparation of source tree’, so it seems post 1.7 we have something inbetween solution ?

Re: creating images which include actively developed applications

[Paul Eggleton]

On Wednesday 22 April 2015 23:49:41 Khem Raj wrote:
> > On Apr 22, 2015, at 4:22 PM, Paul Eggleton <paul.eggleton@linux.intel.com>
> > wrote:> 
> > On Wednesday 22 April 2015 20:51:08 Brian Karcz wrote:
> >> Thanks for pointing me to that. It sounds like exactly what I need. I
> >> can't believe that I've not come across that in my searches. I suppose
> >> its a matter of using the right search criteria.
> > 
> > So I do want to mention one thing - we envisaged externalsrc more for
> > situations where you temporarily want to build from an external source
> > tree (for example, when you're in the middle of development). The
> > expectation is that when you reach production you switch over to a
> > standard repository
> > specified in SRC_URI. Having said that there aren't any actual barriers to
> > using it on a more permanent basis as it sounds like you may  be
> > considering (although perhaps I've misunderstood.)
> 
> Application development doesn’t end is what really happens, so developers
> will need to keep using something like this forever on a given application,
> and somehow externalsrc sounds temporary i.e. not included into regular
> workflow.

But does the source tree persist on one developer's machine? Or should it in 
fact be on a proper server in a repository of its own?

> >> 2) can the SRC_URI now be omitted in the recipe since there is nothing to
> >> fetch?
> > 
> > You can leave it completely blank if you wish. In dizzy and earlier,
> > SRC_URI is effectively ignored with externalsrc. In master and the
> > just-released fido release, any local file:// references will still be
> > fetched if present, remote URIs will be ignored.
> 
> Will they be just fetched or also applied to source tree like in
> non-externalsrc case. getting a  'prepared source tree' in an externalsrc
> env is a big confusion point for developers where a given component is
> building totally fine and if one want to use externalsrc then developer
> needs to do ‘preparation of source tree’, so it seems post 1.7 we have
> something inbetween solution ?

They will be unpacked into the workdir as they would have been without 
externalsrc. They do not go into the source tree.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: creating images which include actively developed applications

[Khem Raj]

> On Apr 23, 2015, at 1:45 AM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> 
> On Wednesday 22 April 2015 23:49:41 Khem Raj wrote:
>>> On Apr 22, 2015, at 4:22 PM, Paul Eggleton <paul.eggleton@linux.intel.com>
>>> wrote:> 
>>> On Wednesday 22 April 2015 20:51:08 Brian Karcz wrote:
>>>> Thanks for pointing me to that. It sounds like exactly what I need. I
>>>> can't believe that I've not come across that in my searches. I suppose
>>>> its a matter of using the right search criteria.
>>> 
>>> So I do want to mention one thing - we envisaged externalsrc more for
>>> situations where you temporarily want to build from an external source
>>> tree (for example, when you're in the middle of development). The
>>> expectation is that when you reach production you switch over to a
>>> standard repository
>>> specified in SRC_URI. Having said that there aren't any actual barriers to
>>> using it on a more permanent basis as it sounds like you may  be
>>> considering (although perhaps I've misunderstood.)
>> 
>> Application development doesn’t end is what really happens, so developers
>> will need to keep using something like this forever on a given application,
>> and somehow externalsrc sounds temporary i.e. not included into regular
>> workflow.
> 
> But does the source tree persist on one developer's machine? Or should it in 
> fact be on a proper server in a repository of its own?

its on a SCM as well. Developer checks it out himself or via a tool for workspace management
now you have two ways to build it. One w/o externalsrc which is common for system integrators
but not much liked by developers. The other one is externalsrc which is well known method
for developers.

> 
>>>> 2) can the SRC_URI now be omitted in the recipe since there is nothing to
>>>> fetch?
>>> 
>>> You can leave it completely blank if you wish. In dizzy and earlier,
>>> SRC_URI is effectively ignored with externalsrc. In master and the
>>> just-released fido release, any local file:// references will still be
>>> fetched if present, remote URIs will be ignored.
>> 
>> Will they be just fetched or also applied to source tree like in
>> non-externalsrc case. getting a  'prepared source tree' in an externalsrc
>> env is a big confusion point for developers where a given component is
>> building totally fine and if one want to use externalsrc then developer
>> needs to do ‘preparation of source tree’, so it seems post 1.7 we have
>> something inbetween solution ?
> 
> They will be unpacked into the workdir as they would have been without 
> externalsrc. They do not go into the source tree.

hmm, it will then get my patches and put them in workdir, so then I should manually apply these patches
I see that if i have any config files etc. ( non-patch files) in SRC_URI ponting into local meta-data then they
will be available at WORKDIR location much like the case w/o externalsrc so thats probably slight improvemnt

Re: creating images which include actively developed applications

[Paul Eggleton]

On Thursday 23 April 2015 02:05:49 Khem Raj wrote:
> > On Apr 23, 2015, at 1:45 AM, Paul Eggleton <paul.eggleton@linux.intel.com>
> > wrote:> 
> > On Wednesday 22 April 2015 23:49:41 Khem Raj wrote:
> >>> On Apr 22, 2015, at 4:22 PM, Paul Eggleton
> >>> <paul.eggleton@linux.intel.com>
> >>> wrote:>
> >>> 
> >>> On Wednesday 22 April 2015 20:51:08 Brian Karcz wrote:
> >>>> Thanks for pointing me to that. It sounds like exactly what I need. I
> >>>> can't believe that I've not come across that in my searches. I suppose
> >>>> its a matter of using the right search criteria.
> >>> 
> >>> So I do want to mention one thing - we envisaged externalsrc more for
> >>> situations where you temporarily want to build from an external source
> >>> tree (for example, when you're in the middle of development). The
> >>> expectation is that when you reach production you switch over to a
> >>> standard repository
> >>> specified in SRC_URI. Having said that there aren't any actual barriers
> >>> to
> >>> using it on a more permanent basis as it sounds like you may  be
> >>> considering (although perhaps I've misunderstood.)
> >> 
> >> Application development doesn’t end is what really happens, so developers
> >> will need to keep using something like this forever on a given
> >> application,
> >> and somehow externalsrc sounds temporary i.e. not included into regular
> >> workflow.
> > 
> > But does the source tree persist on one developer's machine? Or should it
> > in fact be on a proper server in a repository of its own?
> 
> its on a SCM as well. Developer checks it out himself or via a tool for
> workspace management now you have two ways to build it. One w/o externalsrc
> which is common for system integrators but not much liked by developers.
> The other one is externalsrc which is well known method for developers.

Right, yes - but is that a problem? In 1.8 with devtool making it easy to 
switch in and out of "development" locally you ought to be able to get the 
best of both worlds.

> >>>> 2) can the SRC_URI now be omitted in the recipe since there is nothing
> >>>> to fetch?
> >>> 
> >>> You can leave it completely blank if you wish. In dizzy and earlier,
> >>> SRC_URI is effectively ignored with externalsrc. In master and the
> >>> just-released fido release, any local file:// references will still be
> >>> fetched if present, remote URIs will be ignored.
> >> 
> >> Will they be just fetched or also applied to source tree like in
> >> non-externalsrc case. getting a  'prepared source tree' in an externalsrc
> >> env is a big confusion point for developers where a given component is
> >> building totally fine and if one want to use externalsrc then developer
> >> needs to do ‘preparation of source tree’, so it seems post 1.7 we have
> >> something inbetween solution ?
> > 
> > They will be unpacked into the workdir as they would have been without
> > externalsrc. They do not go into the source tree.
> 
> hmm, it will then get my patches and put them in workdir, so then I should
> manually apply these patches I see that if i have any config files etc. (
> non-patch files) in SRC_URI ponting into local meta-data then they will be
> available at WORKDIR location much like the case w/o externalsrc so thats
> probably slight improvemnt

One thing I neglected to highlight was in 1.8, if you use devtool modify -x, 
it will apply the patches to for you when preparing the source tree. 
externalsrc doesn't do anything with them though so yes if you want to prepare 
the source tree yourself you will need to apply any patches from the recipe by 
hand, but there is now an easier way to do that with devtool.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: creating images which include actively developed applications

[Mike Looijmans]

On 22-04-15 19:58, Paul Eggleton wrote:
> Hi Brian,
>
> On Wednesday 22 April 2015 15:32:06 Brian Karcz wrote:
>>  ..
>> Is there a way to create a recipe to build actively developed code located
>> in an external source directory? Basically skip the fetch and unpack steps
>> and always execute the compile and populate steps each time and image is
>> built?
>
> Indeed there is:
>
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-software-from-an-external-source

Man, I've been working with OE for years, and this is the first time I ever 
saw this.

You should create a link to this page using ten feet neon tubes. Seriously. 
People have been asking me this question over and over, and all I had to offer 
was some crappy scripts to invalidate and rebuild a package.

Kind regards,
Mike.



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Re: creating images which include actively developed applications

[Trevor Woerner]

On 04/22/15 13:58, Paul Eggleton wrote:
> Hi Brian,
>
> On Wednesday 22 April 2015 15:32:06 Brian Karcz wrote:
>> Is there a way to create a recipe to build actively developed code located
>> in an external source directory? Basically skip the fetch and unpack steps
>> and always execute the compile and populate steps each time and image is
>> built?
> Indeed there is:
>
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#building-software-from-an-external-source
>

Paul, I'm surprised you suggested externalsrc instead of just mentioning
devtool right from the start (doubly-surprised since you're the person
who wrote devtool!). Using devtool the "administration" (of creating a
recipe, etc) is done for you, no?

http://twoerner.blogspot.ca/2015/01/the-yocto-project-introducing-devtool.html

Re: creating images which include actively developed applications

[Paul Eggleton]

On Friday 01 May 2015 16:25:38 Trevor Woerner wrote:
> On 04/22/15 13:58, Paul Eggleton wrote:
> > On Wednesday 22 April 2015 15:32:06 Brian Karcz wrote:
> >> Is there a way to create a recipe to build actively developed code
> >> located in an external source directory? Basically skip the fetch and
> >> unpack steps and always execute the compile and populate steps each time
> >> and image is built?
> > 
> > Indeed there is:
> > 
> > http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#buildi
> > ng-software-from-an-external-source
>
> Paul, I'm surprised you suggested externalsrc instead of just mentioning
> devtool right from the start (doubly-surprised since you're the person
> who wrote devtool!). Using devtool the "administration" (of creating a
> recipe, etc) is done for you, no?
> 
> http://twoerner.blogspot.ca/2015/01/the-yocto-project-introducing-devtool.ht
> ml

Well, I would have, except this doesn't quite seem like the same case as 
devtool is designed for (which is "temporary" switching of the source for 
development - AIUI Brian was looking for something more permanent.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: creating images which include actively developed applications

[Michael_E_Brown]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

Dell - Internal Use - Confidential
We use the google android "repo" tool plus 'externalsrc' to great effect. 3 generations now, across now 6-ish different products and dozens of releases at this point. It checks out poky, our layer, our source mirror, and our internal sources all at once.
--
Michael

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Paul Eggleton
Sent: Tuesday, May 05, 2015 3:32 AM
To: Trevor Woerner
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] creating images which include actively developed applications

On Friday 01 May 2015 16:25:38 Trevor Woerner wrote:
> On 04/22/15 13:58, Paul Eggleton wrote:
> > On Wednesday 22 April 2015 15:32:06 Brian Karcz wrote:
> >> Is there a way to create a recipe to build actively developed code
> >> located in an external source directory? Basically skip the fetch
> >> and unpack steps and always execute the compile and populate steps
> >> each time and image is built?
> >
> > Indeed there is:
> >
> > http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#
> > buildi
> > ng-software-from-an-external-source
>
> Paul, I'm surprised you suggested externalsrc instead of just
> mentioning devtool right from the start (doubly-surprised since you're
> the person who wrote devtool!). Using devtool the "administration" (of
> creating a recipe, etc) is done for you, no?
>
> http://twoerner.blogspot.ca/2015/01/the-yocto-project-introducing-devt
> ool.ht
> ml

Well, I would have, except this doesn't quite seem like the same case as devtool is designed for (which is "temporary" switching of the source for development - AIUI Brian was looking for something more permanent.)

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[-- Attachment #2: Type: text/html, Size: 4549 bytes --]

Re: creating images which include actively developed applications

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 3201 bytes --]


> On May 5, 2015, at 6:35 PM, michael_e_brown@dell.com wrote:
> 
> Dell - Internal Use - Confidential
> 
> We use the google android “repo” tool plus ‘externalsrc’ to great effect. 3 generations now, across now 6-ish different products and dozens of releases at this point. It checks out poky, our layer, our source mirror, and our internal sources all at once.

well, I have similar setup with repo hooks to generate an auto.conf with needed info about externalsrc components from repo groups and it works well however it really depends upon how much software you build on top if its a thick middleware + apps then
we loose the sstate reuse and if you have components which are needing to be dependency for something like qtwebkit then
its going to be even further degraded build performance for developers. Most of the times the dependencies are not changing APIs and interfaces but rebuild still happens since the component has changed we have no way to determine if the components APIs changed or not. It would be nice if build system could have such a tool to register certain APIs which could be added to rebuild decision checksum to make it more fine grained.

> --
> Michael
> 
> -----Original Message-----
> From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Paul Eggleton
> Sent: Tuesday, May 05, 2015 3:32 AM
> To: Trevor Woerner
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] creating images which include actively developed applications
> 
> On Friday 01 May 2015 16:25:38 Trevor Woerner wrote:
> > On 04/22/15 13:58, Paul Eggleton wrote:
> > > On Wednesday 22 April 2015 15:32:06 Brian Karcz wrote:
> > >> Is there a way to create a recipe to build actively developed code
> > >> located in an external source directory? Basically skip the fetch
> > >> and unpack steps and always execute the compile and populate steps
> > >> each time and image is built?
> > >
> > > Indeed there is:
> > >
> > > http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#
> > > buildi
> > > ng-software-from-an-external-source
> >
> > Paul, I'm surprised you suggested externalsrc instead of just
> > mentioning devtool right from the start (doubly-surprised since you're
> > the person who wrote devtool!). Using devtool the "administration" (of
> > creating a recipe, etc) is done for you, no?
> >
> > http://twoerner.blogspot.ca/2015/01/the-yocto-project-introducing-devt
> > ool.ht
> > ml
> 
> Well, I would have, except this doesn't quite seem like the same case as devtool is designed for (which is "temporary" switching of the source for development - AIUI Brian was looking for something more permanent.)
> 
> Cheers,
> Paul
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> https://lists.yoctoproject.org/listinfo/yocto <https://lists.yoctoproject.org/listinfo/yocto>

[-- Attachment #1.2: Type: text/html, Size: 10161 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]