[OE-core] [PATCH v2 0/2] Make source code browsable locally - devtool srctree

[Peter Kjellerstedt]

> -----Original Message-----
> From: Andre McCurdy [mailto:armccurdy at gmail.com]
> Sent: den 31 augusti 2017 22:10
> To: Peter Kjellerstedt <peter.kjellerstedt at axis.com>
> Cc: Tobias Hagelborn <Tobias.Hagelborn at axis.com>; OE Core mailing list
> <openembedded-core at lists.openembedded.org>
> Subject: Re: [OE-core] [PATCH v2 0/2] Make source code browsable
> locally - devtool srctree
> 
> On Wed, Aug 30, 2017 at 11:32 PM, Peter Kjellerstedt
> <peter.kjellerstedt at axis.com> wrote:
> >>
> >> Just for reference, I think you could achieve something quite
> similar
> >> with:
> >>
> >>   bitbake <your-image> --runall clean  ( or rm -rf tmp )
> >>   bitbake <your-image> --runall patch
> >
> > Yes, but the drawback with this is that to find the source code for
> the
> > individual packages, you have to dive down into tmp/work/... which
> can
> > be quite discouraging for someone who is not an expert in bitbake.
> What
> > our developers requested was a way to get easy access to all the
> source
> > code being used, typically to be able to search through it all
> looking
> > for some specific feature.
> 
> Right. I wasn't trying to suggest that the two approaches were
> completely equivalent, just drawing some attention to the bitbake
> --runall option, which was added fairly recently (specifically to
> solve this problem).
> 
> The directory structure split under tmp/work between arch and machine
> specific recipes might be a little confusing but obviously serves a
> purpose (target and native sources may need different sets of patches,
> etc) so maybe worth the effort to explain to developers. Below that
> level I don't think there are many surprises in the paths to the
> sources directories?

Well, the most common request we've gotten from the developers is that 
they want to be able to search through all the sources, e.g., to find 
out where a particular function is used. The tmp directory does not 
lend itself very well to this, given that it also contains all build 
trees, applied patches and other meta information that bitbake needs.
Thus the idea for the parallel tree with only the source references.

//Peter