summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/tinfoil.py
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: tinfoil: ensure get_recipe_info() returns Null if recipe not foundPaul Eggleton2017-11-211-7/+10
| | | | | | | | | | If a matching recipe is not found then return Null instead of raising KeyError because we were blindly using None as a key for pkg_fn. (Bitbake rev: 431e89e322850a2497157c3c0843da9df6bc9a3e) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: Ensure we clean up loggersRichard Purdie2017-11-091-2/+8
| | | | | | | | | | This is primarily paranoid but ensure we remove any loggers we setup either directly or indirectly so the initial state is restored after we exit. (Bitbake rev: af7d63b1f76fd3f7fa92ed15ae61ca47d9e13472) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: ensure variable history tracking works when parsing a recipePaul Eggleton2017-08-311-11/+18
| | | | | | | | | | | | | | | | | | If you set tracking=True when creating the tinfoil object, that ensures history is collected for the main datastore, but at the end of parsing the configuration, history tracking gets turned off to save time with the result that we don't collect history for any recipes we parse. Enable tracking when we parse a recipe (and disable it afterwards if we enabled it) in order to fix this. This fixes functionality in OE's devtool that relies upon variable history (such as devtool upgrade updating PV when it's set within a recipe). (Bitbake rev: cc8b4c81bb589fb70774a0151f87a8d277f40f06) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: ensure log lines get printed when tasks failPaul Eggleton2017-08-311-0/+7
| | | | | | | | | | | | | | If a task fails during build_targets(), we need to print out the log lines as knotty does or the user will be missing information about the failure. (This should get some deeper refactoring, but now isn't the time for that.) (Bitbake rev: 24879df071d4803db3d39ae1d5cad852daa92f28) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: fix log message doubling when config_only=FalsePaul Eggleton2017-08-311-0/+11
| | | | | | | | | | | | | | With config_only=False we launch the UI and it sets up a logger, whereas when config_only=True we don't, with the result that with True we are seeing log messages from both our logger and the one set up by the UI. Suppress our loggers with config_only=True to avoid this. Fixes [YOCTO #11275] (again). (Bitbake rev: b5e3b28b7c982dd8a3991d727f25710dbf58bb80) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Revert "tinfoil: fix duplication of log messages"Paul Eggleton2017-08-091-2/+1
| | | | | | | | | | | | | | | | | In combination with the recent server reworking, this change actually prevents messages sent from tasks from being logged properly. This will of course give us the duplicated messages back, and I really hate to do that effectively a second time, but that's better than seeing no error at all in the case of a failure - we'll have to find the proper way of avoiding the duplication that doesn't result in some messages going missing. This reverts commit 8a5bae76f91f2411187c638a42fa3c762052cf11. (Bitbake rev: 645c8dd15762516ae5ab64a1df47fadb95d072d1) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: add more doc commentsPaul Eggleton2017-07-211-0/+65
| | | | | | | | | | We want this API to be easier to use, so add missing function documentation to help with that. (Bitbake rev: 3e0e002d6497caa987f327cd83ad4db82cca6810) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: add simple API for getting cached recipe informationPaul Eggleton2017-07-211-0/+142
| | | | | | | | | | | | | | | | | | | | | A common task for tinfoil-using scripts is to iterate over all recipes. This isn't too difficult with the current API, but the pkg_* variables are a little awkward and are really designed for bitbake's internal usage - and it gets a bit more difficult when you want to access some of the other information such as packages and rprovides. To resolve this, create a new recipe info class and add an all_recipes() function to generate this for all recipes. Also add a get_recipe_info() function to get the information for a specific recipe (by PN). (It might perhaps be suggested that we already have a structure similar to this in the cache, however the one we add here is designed for external use and allows the internal structures to change if needed without affecting the API). (Bitbake rev: 308994028e59735ca726c5d2c1f0f85baccfe89d) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: enable access to additional cached itemsPaul Eggleton2017-07-211-0/+8
| | | | | | | | | | | Add access to fn_provides, packages, packages_dynamic and rproviders on the recipecache object. This requires an additional corresponding command plumbing to be added. (Bitbake rev: 3df9b7c615174a6557581f3cd157842a28f6bb26) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: add functionality for running full buildsPaul Eggleton2017-07-211-0/+154
| | | | | | | | | | | | | | | | Up to this point, if you wanted to run build tasks in the normal way they get run from a python script, there was no other way than to shell out to bitbake. Worse than that, you couldn't have tinfoil active during that because only one bitbake instance could be running at once. As long as we're prepared to handle the events produced, we can create a wrapper around calling the buildTargets command. Borrow code from knotty to do this in such a way that we get the expected running task display (courtesy of TermFilter) and Ctrl+C handling. (Bitbake rev: 43761eee756be52a1021be53a40dc591a6c35fa7) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: set a flag when recipes have been parsedPaul Eggleton2017-07-211-0/+3
| | | | | | | | | | Make it easy to determine if recipes are parsed (and thus information about available recipes is in memory). (Bitbake rev: 7efde2df2ff25063d36ac015146f1975284a69ff) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: add a parse_recipes() functionPaul Eggleton2017-07-211-1/+7
| | | | | | | | | | | | Python style recommends underscore based naming rather than camelCase, and thus the former has been used for most of tinfoil's functions. Add an underscored version of parseRecipes() for consistency and change the one place we call it to use the new version. (Bitbake rev: 821f6c41d850752d2bcc2ccd4f8e75b2897a0a3e) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: add internal mode to build_file() functionPaul Eggleton2017-07-211-3/+6
| | | | | | | | | | | | | | | | | In OE's devtool we want to repeatedly run build_file() without showing unnecessary messages and triggering buildhistory for each call. build_file() is just a wrapper around the buildFile command. Change the final "hidewarning" parameter of the buildFile command to "internal" and have this call a new buildFileInternal() function without triggering any of the normal build events, silencing the normal info messages from the runqueue ("Executing RunQueue Tasks", "Tasks Summary" etc.) and avoiding calling parseConfiguration() which we've already done at this point. (Bitbake rev: ba53e067a2d448dd63b4ca252557ce98aa8e6321) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server: Rework the server API so process and xmlrpc servers coexistRichard Purdie2017-07-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes the way bitbake server works quite radically. Now, the server is always a process based server with the option of starting an XMLRPC listener on a specific inferface/port. Behind the scenes this is done with a "bitbake.sock" file alongside the bitbake.lock file. If we can obtain the lock, we know we need to start a server. The server always listens on the socket and UIs can then connect to this. UIs connect by sending a set of three file descriptors over the domain socket, one for sending commands, one for receiving command results and the other for receiving events. These changes meant we can throw away all the horrid server abstraction code, the plugable transport option to bitbake and the code becomes much more readable and debuggable. It also likely removes a ton of ways you could hang the UI/cooker in weird ways due to all the race conditions that existed with previous processes. Changes: * The foreground option for bitbake-server was dropped. Just tail the log if you really want this, the codepaths were complicated enough without adding one for this. * BBSERVER="autodetect" was dropped. The server will autostart and autoconnect in process mode. You have to specify an xmlrpc server address since that can't be autodetected. I can't see a use case for autodetect now. * The transport/servetype option to bitbake was dropped. * A BB_SERVER_TIMEOUT variable is added which allows the server to stay resident for a period of time after the last client disconnects before unloading. This is used if the -T/--idle-timeout option is not passed to bitbake. This change is invasive and may well introduce new issues however I believe the codebase is in a much better position for further development and debugging. (Bitbake rev: 72a3dbe13a23588e24c0baca6d58c35cdeba3f63) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: fix duplication of log messagesPaul Eggleton2017-06-121-1/+2
| | | | | | | | | | | | | | | Adding an additional logger in setup_bitbake() interacts poorly with the logger we have added by default in tinfoil's constructor, with the result that messages may be doubled or even tripled in tinfoil-using scripts. Disable adding this one when calling setup_bitbake() from tinfoil to avoid this problem. Part of the fix for [YOCTO #11275]. (Bitbake rev: 8a5bae76f91f2411187c638a42fa3c762052cf11) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: allow extra features to be passed to prepareAndy Voltz2017-06-051-1/+4
| | | | | | | (Bitbake rev: 2e35de1f19dc73a61a18a3eb186efede078d597d) Signed-off-by: Andy Voltz <andy.voltz@timesys.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: improve get_recipe_file() exception textPaul Eggleton2017-03-311-2/+2
| | | | | | | | | | | | * Turn reasons from a list into a string (usually there will be only one reason, but the interface provides for more than one) and state up front that the recipe is unavailable for clarity * Use quotes around invalid recipe name (Bitbake rev: 8922f1d23400049d2894a97915a533769a24ca07) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: fix get_recipe_file() to return an error on invalid recipePaul Eggleton2017-03-311-1/+1
| | | | | | | | | | | | | This function calls cooker.findBestProvider() but didn't handle the fact that that function returns a tuple (None, None, None, None) when there is no matching recipe. (This fixes devtool in OpenEmbedded showing a traceback when an invalid recipe is specified instead of a proper error message.) (Bitbake rev: 54a4757ca706afc6e98c7692f960592e80cab12b) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: enable client-side logger handling by defaultPaul Eggleton2017-03-271-1/+5
| | | | | | | | | | | | | | | | If you had a script that uses tinfoil and it failed to connect to the BitBake server, you did't see any of the expected messages - this was because client-side logging wasn't being handled at all. Since you'll almost always want this when using tinfoil, have it use the new bb.msg.logger_create() function to enable client-side logging by default. Relates to [YOCTO #11185]. (Bitbake rev: 824e73e0f3eaa96b4d84da7e31f9a17ce5c5d7ee) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: implement missing remote datastore operationsPaul Eggleton2017-03-221-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: fix override handling in remote datastoresPaul Eggleton2017-03-221-2/+5
| | | | | | | | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: ensure PATH includes bitbake's bin directoryPaul Eggleton2017-02-191-0/+13
| | | | | | | | | | | | | | | | | The runqueue expects to be able to run 'bitbake-worker' from PATH, but for example in the OE extensible SDK, tinfoil is used within devtool where this isn't the case (we're not exposing bitbake to the user, thus bitbake's bin directory isn't in PATH). This fixes devtool modify usage within the extensible SDK which has apparently been broken since the tinfoil2 changes went in. Fixes [YOCTO #11034]. (Bitbake rev: 52d87e4a58a52174e8e0b6297abaac8fd93ffcc3) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: allow buildFile warning to be hidden programmaticallyPaul Eggleton2016-12-141-2/+2
| | | | | | | | | | If we want to use this function/command internally, we don't want this warning shown. (Bitbake rev: 5cfbb60833e7b12d698c1c2970c17ccf2a4971bf) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: pass datastore to server when expanding python referencesPaul Eggleton2016-12-141-2/+4
| | | | | | | | | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: implement server-side recipe parsingPaul Eggleton2016-12-141-17/+37
| | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: rewrite as a wrapper around the UIPaul Eggleton2016-12-141-60/+325
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: add a parse_recipe_file functionPaul Eggleton2016-09-021-0/+36
| | | | | | | | | | | | | | | Parsing a recipe is such a common task for tinfoil-using scripts, and is a little awkward to do properly, so add an API function to do it. This should also isolate scripts a little from future changes to the internal code. The first user of this will be the OpenEmbedded layer index update script. Part of the fix for [YOCTO #10192]. (Bitbake rev: 39780b1ccbd76579db0fc6fb9369c848a3bafa9d) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: add context manager functionsPaul Eggleton2016-09-021-0/+6
| | | | | | | | | | | | | | | Since calling the shutdown() function is highly recommended, make tinfoil objects a little easier to deal with by adding context manager support - so you can do the following: with bb.tinfoil.Tinfoil() as tinfoil: tinfoil.prepare(True) ... (Bitbake rev: f59bc6be2b4af1acdcf6a1b184956b5ffd297743) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Initial multi-config supportRichard Purdie2016-08-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the notion of supporting multiple configurations within a single build. To enable it, set a line in local.conf like: BBMULTICONFIG = "configA configB configC" This would tell bitbake that before it parses the base configuration, it should load conf/configA.conf and so on for each different configuration. These would contain lines like: MACHINE = "A" or other variables which can be set which can be built in the same build directory (or change TMPDIR not to conflict). One downside I've already discovered is that if we want to inherit this file right at the start of parsing, the only place you can put the configurations is in "cwd", since BBPATH isn't constructed until the layers are parsed and therefore using it as a preconf file isn't possible unless its located there. Execution of these targets takes the form "bitbake multiconfig:configA:core-image-minimal core-image-sato" so similar to our virtclass approach for native/nativesdk/multilib using BBCLASSEXTEND. Implementation wise, the implication is that instead of tasks being uniquely referenced with "recipename/fn:task" it now needs to be "configuration:recipename:task". We already started using "virtual" filenames for recipes when we implemented BBCLASSEXTEND and this patch adds a new prefix to these, "multiconfig:<configname>:" and hence avoid changes to a large part of the codebase thanks to this. databuilder has an internal array of data stores and uses the right one depending on the supplied virtual filename. That trick allows us to use the existing parsing code including the multithreading mostly unchanged as well as most of the cache code. For recipecache, we end up with a dict of these accessed by multiconfig (mc). taskdata and runqueue can only cope with one recipecache so for taskdata, we pass in each recipecache and have it compute the result and end up with an array of taskdatas. We can only have one runqueue so there extensive changes there. This initial implementation has some drawbacks: a) There are no inter-multi-configuration dependencies as yet b) There are no sstate optimisations. This means if the build uses the same object twice in say two different TMPDIRs, it will either load from an existing sstate cache at the start or build it twice. We can then in due course look at ways in which it would only build it once and then reuse it. This will likely need significant changes to the way sstate currently works to make that possible. (Bitbake rev: 5287991691578825c847bac2368e9b51c0ede3f0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: remove logging handler at shutdownMarkus Lehtonen2015-09-231-4/+5
| | | | | | | | | | | Otherwise the logger gets multiple handers (and the user get duplicate logging output) if another tinfoil instance is initialized after one is shut down(). (Bitbake rev: 74d67be7a4b591fab2278f7c184f282d11620c62) Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: properly fix bitbake.lock handlingRichard Purdie2015-08-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the PR server or indeed any other child process takes some time to exit (which it sometimes does when saving its database), it can end up holding bitbake.lock after the UI exits, which led to errors if you ran bitbake commands successively - we saw this when running the PR server oe-selftest tests in OE-Core. The recent attempt to fix this wasn't quite right and ended up breaking memory resident bitbake. This time we close the lock file when cooker shuts down (inside the UI process) instead of unlocking it, and this is done in the cooker code rather than the actual UI code so it doesn't matter which UI is in use. Additionally we report that we're waiting for the lock to be released, using lsof or fuser if available to list the processes with the lock open. The 'magic' in the locking is due to all spawned subprocesses of bitbake holding an open file descriptor to the bitbake.lock. It is automatically unlocked when all those fds close the file (as all the processes terminate). We close the UI copy of the lock explicitly, then close the server process copy, any remaining open copy is therefore some proess exiting. (The reproducer for the problem is to set PRSERV_HOST = "localhost:0" and add a call to time.sleep(20) after self.server_close() in lib/prserv/serv.py, then run "bitbake -p; bitbake -p" ). Cleanup work done by Paul Eggleton <paul.eggleton@linux.intel.com>. This reverts bitbake commit 69ecd15aece54753154950c55d7af42f85ad8606 and e97a9f1528d77503b5c93e48e3de9933fbb9f3cd. (Bitbake rev: a29780bd43f74b7326fe788dbd65177b86806fcf) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: Add shutdown methodRichard Purdie2015-07-241-0/+4
| | | | | | | | | | | | One drawback to tinfoil is that once a cooker is created, it will hold the cooker lock and stop any other bitbake execution against a directory. Add a shutdown method to tinfoil, allowing other users to use the build directory after the tinfoil usage is no longer needed. (Bitbake rev: e44ce85fe551677fc0dcc1da4f789a0c13093ff1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bin/bitbake: Create bitbake_main APIEd Bartosh2015-03-251-1/+1
| | | | | | | | | | Moved most of functionality of bin/bitbake to lib/bb/main.py to be able to call bitbake from python code. (Bitbake rev: d377f7f88d73f4e5d2dffef03d6acee809827ac6) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: add a means of enabling variable history trackingPaul Eggleton2014-09-051-3/+6
| | | | | | | | | | | | | | | Unfortunately it seems like the external use of the cooker enableDataTracking() function broke at some point since the code that reads it now runs within BBCooker's constructor. Since this now has to be done early, add a parameter to Tinfoil's constructor to allow enabling variable history tracking. Fixes [YOCTO #6676]. (Bitbake rev: a9439b136f55f3f0e80ff053cd3b159da69ba362) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: fix for move of data attribute to cookerPaul Eggleton2013-06-101-1/+1
| | | | | | | (Bitbake rev: c400fe36f7609d53fb413484dc03bbce307f31f9) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/cookerdata: Improve configuration object handlingRichard Purdie2013-05-241-5/+0
| | | | | | | | | | | | | | | | | | | | | Originally it seemed like a good idea to keep the parameters around. Having seen this in real life use, its incorrect, we should pull all the data we need into the cooker's configuguration and then use this to build the datastore. Being able to just build the datastore from the parameters seemed like a good idea but having a dummy cooker configuration object is now looking like the better option. This also fixes failures in hob since the parseFiles command can call into cooker directly now and reset the configuration prefiles and postfiles at will, rather than the indirect calls before which were breaking the datastore (e.g. BBPATH wasn't set). The cleanup this allows in tinfoil illustrates how this change makes more sense. (Bitbake rev: f50df5b891bf318f12fc61c74adfcc626cc6f836) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: fix for changes to cooker config structurePaul Eggleton2013-05-221-20/+21
| | | | | | | | | | Fix the code here for recent changes to the initialisation of configuration objects for cooker. (Bitbake rev: 9d3ca9aa73a448b0594f03ac8e8317403ec0dc8d) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/bitbake-layers/tinfoil: Fix recipecache typoRichard Purdie2013-05-131-2/+2
| | | | | | (Bitbake rev: 0f5eee689992f84d263cb817dc2ce755a9a075f7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-layers/tinfoil: Catch up with status -> recpiecache renameRichard Purdie2013-05-121-2/+2
| | | | | | (Bitbake rev: 0a9cbe7a6a17c5df38cd442ee8650097d6bbf502) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: support other fds, enable color supportChristopher Larson2013-01-311-3/+5
| | | | | | | | | | Rather than only handling sys.stdout, also support any arbitrary file object, and enable color for the formatter if that file is a tty. (Bitbake rev: c46db4be4cc4dc53376ed3f574b2f1c868730f2a) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: Add file inadvertently not committedRichard Purdie2012-09-101-0/+98
(Bitbake rev: 44a3fb49e817be641090d5d1bce7b586af407d71) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-13 18:41:57 +0000