openembedded-core.git/meta/lib/oe/recipeutils.py, branch uninative-1.5

meta: remove True option to getVar calls

2016-12-16T08:30:03+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\)

Signed-off-by: Joshua Lock 
Signed-off-by: Ross Burton

lib/oe/recipeutils: drop parse_recipe_simple()

2016-12-14T09:56:36+00:00

This was intended to be used with tinfoil, but tinfoil now has its own
parse_recipe() method to do this which works properly in the memres
case.

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

classes/patch: move several functions to oe.patch

2016-12-14T09:56:35+00:00

Move patch_path(), src_patches() and should_apply() to oe.patch, making
them easier to call from elsewhere (particularly across the
UI/server boundary).

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

lib/oe/recipeutils: use cooker function instead of bb.providers

2016-12-14T09:56:35+00:00

We now have a function in cooker itself that can do this lookup;
additionally, the rewritten tinfoil's cooker adapter has its own
implementation that can work remotely, so if we use it then this
function can work in that scenario as well.

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

lib/oe/recipeutils: ignore archives by default in get_recipe_local_files()

2016-11-23T11:02:27+00:00

By default, have get_recipe_local_files() not return any archive
files. This prevents a local tarball from being erroneously removed
from SRC_URI if you run "devtool modify" on a recipe followed by
"devtool update-recipe". It doesn't actually help you to directly
update the contents of such tarballs, but at least now it won't break
the recipe.

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

devtool: update-recipe: fix handling of compressed local patches

2016-11-23T11:02:27+00:00

It is possible to use gzip or bzip2 to compress patches and still refer
to them in compressed form in the SRC_URI value within a recipe. If you
run "devtool modify" on such a recipe, make changes to the commit for
the patch and then run devtool update-recipe, we need to correctly
associate the commit back to the compressed patch file and re-compress
the patch, neither of which we were doing previously.

Additionally, add an oe-selftest test to ensure this doesn't regress in
future.

Fixes [YOCTO #8278].

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

lib/oe/recipeutils: print just filename in bbappend_recipe() if in temp dir

2016-11-06T23:35:23+00:00

If you use devtool update-recipe with the --append option, and a "local"
(in oe-local-files) has been modified we copy it into the specified
destination layer. With the way the devtool update-recipe code works now
the source is always a temp directory, and printing paths from within
that is just confusing, so if the path starts with the temp directory
then just print the file name alone.

Signed-off-by: Paul Eggleton 
Signed-off-by: Ross Burton

lib/oe/recipeutils: fix invalid character detection in validate_pn()

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

* validate_pn() is supposed to protect against invalid characters, fix
  the function so that it actually does (unanchored regex strikes
  again...)
* However, now that the function is enforcing the restrictions, we do
  still want to allow + in recipe names (e.g. "gtk+")

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

devtool: update-recipe: support files with subdir=

2016-09-07T23:36:43+00:00

It's rare but there are recipes that have individual files (as opposed
to archives) in SRC_URI using subdir= to put them under the source tree,
the examples in OE-Core being bzip2 and openssl. This broke devtool
update-recipe (and devtool finish) because the file wasn't unpacked into
the oe-local-files directory and thus when it came time to update the
recipe, the file was assumed to have been deleted by the user and thus
the file was erroneously removed. Add logic to handle these properly so
that this doesn't happen.

(We still have another potential problem in that these files become part
of the initial commit from upstream, which could be confusing because
they didn't come from there - but that's a separate issue and not one
that is trivially solved.)

Signed-off-by: Paul Eggleton

devtool/recipetool/meta: Adapt to bitbake API changes for multi-configuration builds

2016-08-18T08:27:56+00:00

Unfortunately to implenent multiconfig support in bitbake some APIs
had to change. This updates code in OE to match the changes in bitbake.
Its mostly periperhal changes around devtool/recipetool

[Will need a bitbake version requirement bump which I'll make when merging]

Signed-off-by: Richard Purdie