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

Paul Eggleton paul.eggleton at linux.intel.com
Wed Oct 4 18:47:50 PDT 2017


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?

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

> 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. 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).

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



More information about the yocto mailing list