openembedded-core.git/scripts/lib/recipetool, branch morty

recipetool: fix encoding-related errors creating python recipes

2017-01-11T11:46:47+00:00

Yet another instance of us expecting a string back from subprocess when
in Python 3 what you get back is bytes. Just decode the output within
run_command() so we avoid this everywhere.

(From OE-Core rev: 103faae78cdff5280c7b7cdb7ca01e0868d02ec9)

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

devtool: add: build nodejs-native if npm is needed and not available

2016-10-04T23:12:25+00:00

If the user runs devtool add on an npm:// URL (or source tree that uses
node.js), and npm is not available, just build nodejs-native instead of
telling the user they need to do it; if that fails because there isn't
any such recipe (which would be the default, since it's not in OE-Core)
then produce a slightly more readable error message hinting at what the
user needs to do.

Note that this forces the use of nodejs-native rather than npm on the
host - this makes sense for two reasons: (1) we need it to be compatible
with nodejs for the target, and (2) we have to have a recipe for that
anyway, so allowing you to avoid having a recipe for the native version
isn't really beneficial.

There's a bit of a hack in here in order to allow this - for node.js
sources that aren't fetched via npm we don't know that they are that
until we've fetched and unpacked them, by which time we're inside
recipetool and have an active tinfoil instance that will prevent bitbake
being run. To avoid this being an issue, we allow recipetool to get to
the point where we know we need npm and then exit with a specific exit
code, at which point devtool can try to build it and then if that
succeeds, it will re-execute recipetool. This is definitely not ideal,
but it can't really be refactored and done properly until we do the
tinfoil2 refactoring; in the mean time though we still want to be
helpful to the user.

Fixes [YOCTO #10337].

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

recipetool: newappend: drop _provide_to_pn

2016-09-28T09:15:55+00:00

This function was broken by the multi-config changes, and isn't needed anymore
now that recipeutils.pn_to_recipe can handle provides. Without this, the
newappend sub-command fails.

Signed-off-by: Christopher Larson 
Signed-off-by: Richard Purdie

recipetool: create: support git short form URLs

2016-09-19T08:06:52+00:00

In keeping with making recipetool create / devtool add as easy to use as
possible, users shouldn't have to know how to reformat git short form ssh
URLs for consumption by BitBake's fetcher (for example
user@git.example.com:repo.git should be expressed as
git://user@git.example.com/repo.git;protocol=ssh ) - instead we should
just take care of that automatically. Add some logic in the appropriate
places to do that.

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

recipetool: create: tweak license crunching

2016-09-19T08:06:52+00:00

Filter out a plain "Licensed under the XXXX license" statement, as seen
in the capnproto project (and no doubt others).

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

recipetool: create: pick up AC_PROG_SWIG

2016-09-19T08:06:52+00:00

AX_PKG_SWIG is not the only commonly-used macro for detecting swig -
there's also AC_PROG_SWIG. As per AX_PKG_SWIG, add swig-native to
DEPENDS if AC_PROG_SWIG is found in configure.ac.

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

recipetool: create: detect python autoconf macros

2016-09-19T08:06:52+00:00

If python is required then we need to inherit pythonnative (or
python3native) otherwise do_configure will probably fail since it won't
be able to find python.

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

recipetool: create: fix error with git tree and no network

2016-09-19T08:06:52+00:00

When creating a recipe for an existing local git clone, we attempt to
use the fetcher to determine if it supports the SRCREV variable.
Unfortunately running this code does a network check to get the latest
revision as a direct result of us using '${AUTOREV}' as a default value.
If you don't have a network connection this will of course fail. Rather
than have this block creating the recipe, catch the exception and just
guess from the URL.

Ultimately this should probably be fixed in the fetcher but for now this
will at least resolve the issue on this end.

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

recipetool: create: fix name/version extraction from filename

2016-09-19T08:06:52+00:00

I ran into an example where recipetool was getting the name/version
completely wrong:

https://bitbucket.org/sortsmill/libunicodenames/downloads/libunicodenames-1.1.0_beta1.tar.xz

>From this it would create a libunicodenames-1.1.0-beta1_1.1.0-beta1.bb
file (likely because it couldn't split the file name and therefore took
all of it, then got the version from one of the files inside the
tarball). When this happens it's just irritating because you then have
to delete the recipe / run devtool reset and then run recipetool create
/ devtool add again and specify the version manually.

This patch is the result of systematically running the
determine_from_filename() function over the files on the Yocto Project
source mirror and my local downloads directory and fixing as many of the
generic issues as reasonably practical - it now gets the name and
version correct much more often. There are still cases where it won't,
but they are now in the minority.

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

recipetool: create: improve python recipe license handling

2016-09-19T08:06:52+00:00

Try to ensure that for Apache, GPL and LGPL where the values extracted
from the "Classifiers" field may not be version-specific, if there is a
versioned license in the free-form license field then use that instead.
Also insert the free-form license field as a comment in the recipe for
the user's reference.

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie