linux/poky.git/bitbake/lib/bb/command.py, branch yocto-2.3.1

bitbake: lib/bb/command: fix overrides in remote datastores where there is no default

2017-04-20T06:59:40+00:00

If you have, for example, no value set for a variable VARIABLE and a then VARIABLE_pn-something = "value" and then you parse something.bb, you expect getVar('VARIABLE') on the resulting datastore to return "value", but the code here assumed that if the variable wasn't set without overrides then we didn't need to return the overridedata and thus we didn't get the overridden value. In OE this affected the ability to get RECIPE_MAINTAINER for a recipe in a script using tinfoil (since this is only set from an inc file with _pn- overrides for each recipe, and no default is set). (Bitbake rev: b3d2c9917c5fd8278878328794daa107ddf79b64) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: command.py: multiconfig support for findBestProvider

2017-04-19T09:20:24+00:00

In a multiconfig environment, a tinfoil call such as tinfoil.parse_recipe("multiconfig:arduino-101-sss:gcc") can fail with an error such as: File "/data/master/poky/bitbake/lib/bb/tinfoil.py", line 373, in get_recipe_file raise bb.providers.NoProvider('Unable to find any recipe file matching "%s"' % pn) bb.providers.NoProvider: Unable to find any recipe file matching "multiconfig:arduino-101-sss:gcc" The culprit is findBestProvider, which does not handle multiconfig. This patch fixes the error and in the case mentioned above the tinfoil call returns: "multiconfig:arduino-101-sss:/data/master/poky/meta/recipes-devtools/gcc/gcc_6.3.bb" [YOCTO#11210] (Bitbake rev: e9c03fbfd7b057b28645affa263cb4aebfa24b04) Signed-off-by: Juro Bystricky Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

bitbake: data_smart: implement missing remote datastore operations

2017-03-22T11:35:22+00:00

Enable the following operations from a remote datastore to affect the other end: * setVarFlag() * delVar() * delVarFlag() * renameVar() In practice I don't expect these to be used much, but they should be present so that the implementation is at least reasonably filled out and that the tests pass. Also add tests for the interface, mostly by subclassing the existing local test classes so that they are using a remote datastore. (These don't actually test remote usage via tinfoil, just that the datastore's interface can be used.) (Bitbake rev: 282dc0719d22a39df746eea762ebe05c66aa8f8a) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: tinfoil: fix override handling in remote datastores

2017-03-22T11:35:22+00:00

There was a huge gap in the remote datastore code introduced in the tinfoil2 rework - we weren't handling overrides at all, since these are stored separately from the actual data in the DataSmart object. Thus, when a datastore actually represents a remote datastore we need to go back to that remote datastore to get the override data as well, so introduce code to do that. To avoid a second round-trip I had to modify the _findVar() function to return the override data as well. This will increase the overhead a little when that data is superfluous, but without making the function even uglier I don't think there's a way to avoid that. (Bitbake rev: 4f9d6f060ed247fb6fa2f45668a892a1788d3f91) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: cooker/command: Drop expanded_data

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

Some of our metadata assumes that BuildStarted and BuildCompleted events see the same data store. This is the case for buildTarget but not for buildFile and recent changes mean this is now a problem. The update_data() call is now an empty operation and there is no difference between the expanded_data and data so we can simply remove the expanded_data and its references and use data everywhere. This has been inteded for a while but the above issue makes this more pressing to finally clean up. (Bitbake rev: e3694e738e98f26f413ada6860ca7d829d3662f0) Signed-off-by: Richard Purdie

bitbake: runqueue: enable setVariable command to affect task execution

2016-12-14T12:25:07+00:00

Allow the client to set variables with the setVariable command and have those changes take effect when running tasks. This is accomplished by collecting changes made by setVariable separately and pass these to the worker so it can be applied on top of the datastore it creates. (Bitbake rev: 69a3cd790da35c3898a8f50c284ad1a4677682a4) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: cooker: allow buildFile warning to be hidden programmatically

2016-12-14T12:25:07+00:00

If we want to use this function/command internally, we don't want this warning shown. (Bitbake rev: 5cfbb60833e7b12d698c1c2970c17ccf2a4971bf) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: tinfoil: pass datastore to server when expanding python references

2016-12-14T12:25:07+00:00

If you're expanding a value that refers to the value of a variable in python code, we need to ensure that the datastore that gets used to get the value of that variable is the client-side datastore and not just the part of it that's on the server side. For example, suppose you are in client code doing the following: d.setVar('HELLO', 'there') result = d.expand('${@d.getVar("HELLO", True)}') result should be "there" but if the client part wasn't taken into account, it would be whatever value HELLO had in the server portion of the datastore (if any). (Bitbake rev: cbc22a0a9aadc8606b927dbac0f1407ec2736b35) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: tinfoil: implement server-side recipe parsing

2016-12-14T12:25:07+00:00

It's not really practical for us to parse recipes on the client side, we need to do it on the server because that's where we have the full python environment (including any "pure" python functions defined in classes). Thus, add some functions to tinfoil do this including a few shortcut functions. (Bitbake rev: 8f635815d191c9d848a92d51fdbf5e9fd3da1727) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: tinfoil: rewrite as a wrapper around the UI

2016-12-14T12:25:07+00:00

Rewrite tinfoil as a wrapper around the UI, instead of the earlier approach of starting up just enough of cooker to do what we want. This has several advantages: * It now works when bitbake is memory-resident instead of failing with "ERROR: Only one copy of bitbake should be run against a build directory". * We can now connect an actual UI, thus you get things like the recipe parsing / cache loading progress bar and parse error handling for free * We can now handle events generated by the server if we wish to do so * We can potentially extend this to do more stuff, e.g. actually running build operations - this needs to be made more practical before we can use it though (since you effectively have to become the UI yourself for this at the moment.) The downside is that tinfoil no longer has direct access to cooker, the global datastore, or the cache. To mitigate this I have extended data_smart to provide remote access capability for the datastore, and created "fake" cooker and cooker.recipecache / cooker.collection adapter objects in order to avoid breaking too many tinfoil-using scripts that might be out there (we've never officially documented tinfoil or BitBake's internal code, but we can still make accommodations where practical). I've at least gone far enough to support all of the utilities that use tinfoil in OE-Core with some changes, but I know there are scripts such as Chris Larson's "bb" out there that do make other calls into BitBake code that I'm not currently providing access to through the adapters. Part of the fix for [YOCTO #5470]. (Bitbake rev: 3bbf8d611c859f74d563778115677a04f5c4ab43) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie