[yocto] 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 at 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 at 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