[yocto] local fetcher and devtool don't work well together

[Aaron_Wright at selinc.com]

Paul Eggleton <paul.eggleton at linux.intel.com> wrote on 10/04/2017 06:47:50 
PM:
> Hi Aaron,
> 
> On Thursday, 5 October 2017 11:54:32 AM NZDT Aaron_Wright at selinc.com 
wrote:
> > I have a recipe with:
> > 
> > SRC_URI = "file://a/b/c/d;subdir=src"
> > S = "${WORKDIR}/src/a/b/c/d"
> > 
> > First off, ${S} must be set to the full path because the basepath uri 
> > parameter[1] doesn't work. So this doesn't work:
> > 
> > SRC_URI = "file://a/b/c/d;subdir=src;basepath=a/b/c/d"
> > S = "${WORKDIR}/src"
> > 
> > I wish it would, but that's ok. I can deal with the long ${S} path as 
it 
> > compiles and works fine with bitbake. 
> 
> My question would be what are you trying to achieve here? Should you be 
using
> the externalsrc class perhaps?

I've waffled between externalsrc and the local fetcher, but the local 
fetcher seems to behave the best.

What I'm trying to do is a little odd, but we are trying to use yocto with 
the recipes, meta layer, and source code in the same repository. This 
makes the continuous integration server much simpler, and developers can 
see the results of their commit/push in the context of the whole product 
being put together with yocto.

This might not be the best idea, and yocto certainly seems to be based on 
the fact that the source is remote, but things are generally working well 
for us; at least continuous integration server wise. Right now I'm trying 
to figure out how to get developers developing.

>   https://urldefense.proofpoint.com/v2/url?
> 
u=http-3A__www.yoctoproject.org_docs_current_dev-2Dmanual_dev-2Dmanual.html-23building-2Dsoftware-2Dfrom-2Dan-2Dexternal-2Dsource&d=DwICAg&c=zVFQZQ67ypsA9mYKSCqWmQHiVkCCaN-
> Gb60_N6TVnLk&r=rUGbzRLPRvFX3fKfyNvK9Xgz1MfBXwYtoWGtKfkzG3k&m=o9VVMczGF-
> R7-
> 
EC8L6cShpCsU-3GWfug-0DbDpHLamU&s=JFZPoF89tSSrPhrhqmYSV5VrbkGpTM4jsqr1ij9sBa4&e=
> 
> > However, it doesn't work with 
> > devtool:
> > 
> > $ devtool modify -n d ~/mysrc/a/b/c/d
> > NOTE: Creating workspace layer in <... snip 
> > ...>/yocto/poky/build/workspace
> > NOTE: Enabling workspace layer in bblayers.conf
> > Parsing recipes..done.
> > NOTE: Recipe d now set up to build from ~/mysrc/a/b/c/d/b/c/d
> > 
> > Where is the extra 'b/c/d' coming from in where it will be built from? 

> > This directory is reflected in the bbappends created the workspace:
> > 
> > FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> > FILESPATH_prepend := "~/mysrc/a/b/c/d/b/c/d/oe-local-files:"
> >
> > Is it possible to have a ${S} of "${WORKDIR}/src" in this situation?
> > How can I get devtool to behave and not duplicate the path?
> 
> The ~ shouldn't be in the value of FILESPATH, it ought to be expanded, 
so
> that's something we need to fix. 

Don't worry about the ~, that was just something I passed in the email to 
obscure my path. Sorry.

> With regard to the path doubling of the
> subdirectories, it's assuming that because you have that subdirectory 
path in
> S then you need that underneath the specified source directory (since 
that is
> usually true if you were for example pointing to a checkout of a git
> repository, or an extracted source tarball).

You are correct. I can't believe I didn't think of that before. Thank you 
so much. That gets me going at least.

> devtool hasn't been written to handle this usage (which is unusual 
-typically
> the recipe is pointing at remote source). It would be good to get an
> understanding of your use case here so we can figure out where to go 
from
> here.
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20171005/7c4ef8e6/attachment.html>