linux/poky.git/scripts/lib/recipetool, branch 2.3_M2

scripts: remove True option to getVarFlag calls

2016-12-16T10:23:23+00:00

getVarFlag() now defaults to expanding by default, thus remove the True option from getVarFlag() calls with a regex search and replace. Search made with the following regex: getVarFlag ?\(( ?[^,()]*, ?[^,()]*), True\) (From OE-Core rev: 3e4806063fe11092b2307f113a6c0b0f04104091) Signed-off-by: Joshua Lock Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

scripts: remove True option to getVar calls

2016-12-16T10:23:23+00:00

getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) (From OE-Core rev: 0a36bd96e6b29fd99a296efc358ca3e9fb5af735) Signed-off-by: Joshua Lock Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool / recipetool: use tinfoil parsing API

2016-12-14T12:30:49+00:00

Use Tinfoil.parse_recipe_file() and Tinfoil.parse_recipe() instead of the recipeutils equivalents, and replace any local duplicate implementations. This not only tidies up the code but also allows these calls to work in memres mode. (From OE-Core rev: f13b56266ee96dfab65a3a7db50e8051aa9f071a) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

recipetool: fix encoding-related errors creating python recipes

2016-12-08T10:31:29+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

recipetool: add postinst to .deb import

2016-11-23T11:10:14+00:00

The .deb import feature did not import postinst, postrm, preinst, or prerm functions. This change checks to see if those files exist, and if so, adds the appropriate functions. [ YOCTO #10421 ] (From OE-Core rev: ebb73aa6ad920bfd6a23f8c20105d6bcf07dd3d5) Signed-off-by: Stephano Cetola Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

recipetool: create: separate LICENSE items with & by default

2016-11-07T11:04:22+00:00

recipetool sets the LICENSE value based on licenses detected from the source tree. If there are multiple licenses then they were being separated by spaces, but this isn't actually legal formatting and if you're using "devtool add" you get a warning printed when devtool parses the recipe internally. Earlier I had made a conscious decision to do it this way since it's up to the user to figure out whether the multiple licenses should all apply (in which case they'd be separated with &) or if there is a choice of license (in which case | is the correct separator). However, I've come to the conclusion that we can just default to & and then the ugly warning goes away, and it's the safest alternative of the two (and most likely to be correct, since it's more common to have a codebase which is made up of code with different licenses, i.e. all of them apply to the combined work). I've tweaked the comment that we add to the recipe to explicitly state that we've used & and that the user needs to change that if that's not accurate. Fixes [YOCTO #10413]. (From OE-Core rev: ecac6aee8cf3313350b58c21012bcd67cfb915e4) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: add: show recipetool create output

2016-11-07T11:04:22+00:00

When running devtool add, instead of hiding the recipetool create output, change it so that it's appropriate to show in the devtool context and show it in real-time. This means that you get status output such as when a URL is being fetched (though currently no progress information.) recipetool create now has a hidden --devtool option to enable this display mode. (From OE-Core rev: 219aec8803de4ef04c514c87ecfb15359c9424a6) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

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

2016-10-05T09:10:11+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]. (From OE-Core rev: f40662bde5aab158c4e4c3c3ff5e68665a4194a5) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

recipetool: newappend: drop _provide_to_pn

2016-09-28T09:16:04+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. (From OE-Core rev: 4a5028dc3d1ab2f97465e63db5b05de73daebdfa) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

recipetool: create: support git short form URLs

2016-09-20T14:11:07+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. (From OE-Core rev: 78c672a72f49c4b6cfd8c247efcc676b0ba1681a) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie