summaryrefslogtreecommitdiffstats
path: root/bitbake
Commit message (Collapse)AuthorAgeFilesLines
* Drop psyco supportRichard Purdie2011-06-094-21/+0
| | | | | | | | | | | At best it gave 1-2% improvement now, its 32 bit x86 only and isn't supported after python 2.6. PyPy is probably a better option now. (Bitbake rev: 3c3bd0c2fa80d747f25401c17b785c7c2f3787ca) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/data/runqueue: Sync up with upstream to clean up environment ↵Richard Purdie2011-06-082-26/+12
| | | | | | variable handling Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/build.py: Drop exec_shell environment as its now unneededRichard Purdie2011-06-081-6/+1
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* runqueue.py: Wrap parsing with exception trappingRichard Purdie2011-06-081-24/+24
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Shift traceback pre-formatting into LogHandlerChris Larson2011-06-081-4/+1
| | | | | | | | | | | It's cleaner to leave it behaving as usual, passing the exception data in the exc_info attribute of the LogRecord where it normally lies, and then let LogHandler make it pickleable so it can be sent to the UI. (Bitbake rev: 3539c9474a0b53f57e614544c70a7197ecdfb130) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/cooker.py: Misc sync with upstreamRichard Purdie2011-06-084-19/+20
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cooker: use BBHandler.inherit for INHERITChris Larson2011-06-081-10/+24
| | | | | | | | | | | | | | | | | Ideally we'd avoid direct BBHandler usage, but honestly, to say the whole bb.parse abstraction is incredibly leaky is an understatement. If we try to make handle() not reparse classes, things get ugly fairly quickly, as inherit() calls handle() itself after adding the class to the inherit cache. This change fixes it so we no longer risk reparsing a class if: - it's listed in INHERIT multiple times - it's listed in INHERIT and is 'inherit'ed from a class in INHERIT (Bitbake rev: 057c3cddeb72584c6c3908bd702288cece9b66ea) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cooker: simplify self.configuration.data vs data usageChris Larson2011-06-081-10/+9
| | | | | | | (Bitbake rev: 87112adee4e8add0a97ff8be8311d9afe202412d) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cooker: don't choke if we have nothing to parseChris Larson2011-06-081-5/+11
| | | | | | | | | | If all our recipes were cached, there's no reason to fire off any parsing progress events at all. (Bitbake rev: e9e174e5781fc3de4dfd60d01228048a06a62b16) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bb.exceptions: don't choke on frames without argumentsChris Larson2011-06-081-0/+3
| | | | | | | (Bitbake rev: c9bb37e588ee7ee95eca798b0eae57bad68e8caf) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cooker: handle ExpansionError the same way we do ParseErrorChris Larson2011-06-081-1/+1
| | | | | | | (Bitbake rev: 12aef37618bc77fb5ef085d24ad85471fb85c111) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Shift exception formatting into the UIChris Larson2011-06-083-8/+19
| | | | | | | | | | | | | Now we use bb.exceptions to pass pickleable traceback entries to the UI, and the UI is free to do whatever it wants to do with this information. By default, the log formatter for the UIs formats it with bb.exceptions. This also means that all exceptions should now show 3 lines of context and limit to 5 entries. (Bitbake rev: ee48d628ee038bd72e1cd94aa75f5ccbacbcee4c) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cooker: don't show a traceback for ParseErrorChris Larson2011-06-081-0/+2
| | | | | | | (Bitbake rev: cae6bf031dc83ba0439d07584fdbbd4a962408a3) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cooker: don't show a useless traceback for SyntaxErrorChris Larson2011-06-081-1/+4
| | | | | | | | | | Note: we rely on the fact that better_compile has already output information about the exception, so don't do it ourselves. (Bitbake rev: caf21e9fbf3c526c1d7c555d8c76dca8710f9def) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cooker: use logger.exception for config file parse errorsChris Larson2011-06-081-1/+7
| | | | | | | (Bitbake rev: 775590c154bc189df3f5704bddf9b684b734fde0) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cooker: pass traceback back from parsing threadChris Larson2011-06-081-2/+9
| | | | | | | | | | | Uses bb.exceptions to get a traceback back from the parsing thread to the main thread, where it is then formatted. Also enables 3 lines of context for the formatted traceback, and limits the number of entries displayed to 5. (Bitbake rev: 8c33f50eb68411c071c001331e0134aeb776953b) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cooker: show a useful message for ParsingFailureChris Larson2011-06-081-3/+6
| | | | | | | (Bitbake rev: a41c217c6e9195f8b9ea2de6e1d335b10b904558) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bb.exceptions: don't show a repr of 'self'Chris Larson2011-06-081-3/+20
| | | | | | | | | | | | | | Rather than treating self like an ordinary argument, showing a repr of its value in the function spec when formatting the traceback entry, now we show the class name for the method as a part of the function name. Example: Old: bar(self=<some repr of Fooclass>, f=5) New: Fooclass.bar(f=5) (Bitbake rev: dbf405f1f7fda41944093906c13044c6cf78f859) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bb.exceptions: handle tb entries without contextChris Larson2011-06-081-2/+5
| | | | | | | (Bitbake rev: b010c4d37cfff5f74747d7da8cc1bf6719e29357) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bb.exceptions: add to_string convenience functionChris Larson2011-06-081-0/+6
| | | | | | | (Bitbake rev: 17a64df7e91438ee3fe1f7095c319f700a5372f1) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bb.exceptions: add code to create pickleable traceback entriesChris Larson2011-06-081-0/+55
| | | | | | | | | | | | | | | This lets you get as much useful information as possible from traceback entries while staying pickleable. In addition, it has improved traceback formatting. It shows the values of the arguments for the functions, lines of context from the file for the code, and has an optional formatter to do things like syntax highlighting for the code lines. (Bitbake rev: ad8ad3fcae29eafbdc09286984495d693a4b73ef) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bb.namedtuple_with_abc: add useful util from activestateChris Larson2011-06-081-0/+255
| | | | | | | (Bitbake rev: bf9391c60d8dd9eeaca87783cb874c56fa7a4e91) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake-layers: Fixup after recent server changesRichard Purdie2011-06-081-2/+4
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/cooker.py: Fix debug message argumentsRichard Purdie2011-06-081-1/+1
| | | | | | | | (From Poky rev: 06bb59d) (Bitbake rev: b420e865f6dfb04b58c1dbc5f1b5332b137f49ff) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/lib/bb/__init__.py: Sync with upstream bitbakeRichard Purdie2011-06-081-4/+8
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/bin/bitbake: Return an error if exceptions occurRichard Purdie2011-06-081-0/+2
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/server/xmlrpc: Fix typoRichard Purdie2011-06-081-1/+1
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/server/process: Implement getEvent()Richard Purdie2011-06-081-0/+7
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/server/process: Update to new server APIRichard Purdie2011-06-082-34/+79
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Add process server from upstream bitbakeRichard Purdie2011-06-081-0/+221
| | | | Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake none/xmlrpc servers: Only send pickled events to the xmlrpc serverRichard Purdie2011-06-083-4/+6
| | | | | | | Only the xmlrpc server needs pickled events. Use the function names to signify this requirement. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Cleanup bitbake server init process to be clearer to followRichard Purdie2011-06-085-53/+92
| | | | | | | | Create a standard format server class instance with method calls for each step in the server setup. There should be enough hooks for each of the different server types. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Sync up with upstream cosmetic changes for bin/bitbakeRichard Purdie2011-06-081-11/+8
| | | | | | | | Sync cosmetic differences between bitbake in poky and bitbake upstream in preparation for resolving the real code differences in the server handling. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cache: Implement multiple extra cache fields request supportLiping Ke2011-06-072-66/+127
| | | | | | | | | | | | | | This patch is to support extra cache. If user needs to request extra cache fields besides CoreRecipeInfo fields, just add a new XXXRecipeInfo class definition as Hob Does. Currently supported Extra RecipeInfo name is an array. We can support multiple extra cache fields at the same time besides CoreRecipeInfo which is needed by all clients. (Bitbake rev: 077657e50ad032c0fa876bf54e9802af2686e0fb) Signed-off-by: Liping Ke <liping.ke@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Introduce new param caches_array into Cache impl.Liping Ke2011-06-074-14/+57
| | | | | | | | | | | | | | When using hob ui interface, we need extra cache fields. We will save ui required extra cache fields into a separate cache file. This patch introduce this caches_array parameter. It will be used in the extra cache implementation (following patch). Caches_array at least contains CoreRecipeInfo. If users need extra cache fields support, such as 'hob', caches_array will contain more relevant elements such as HobRecipeInfo. (Bitbake rev: d50389ae692377c957afec7c846fc2ce2c070a09) Signed-off-by: Liping Ke <liping.ke@intel.com>
* Introduce extra cache class for image creatorLiping Ke2011-06-071-0/+54
| | | | | | | | | | | | | | | Extra RecipeInfo will be all defined in this file. Currently, Only Hob (Image Creator) Requests some extra fields. So HobRecipeInfo is defined. It's named HobRecipeInfo because it is introduced by 'hob'. Users could also introduce other RecipeInfo or simply use those already defined RecipeInfo. In the following patch, this newly defined new extra RecipeInfo will be dynamically loaded and used for loading/saving the extra cache fields. (Bitbake rev: 75d9add923560af9fdd772a363c68337d2c9a97d) Signed-off-by: Liping Ke <liping.ke@intel.com>
* cache.py: Refactory Current Cache implementationLiping Ke2011-06-071-193/+165
| | | | | | | | | | | | | | | This patch is for refactorying current cache implementation, the main reason is for introducing extra cache fields requests for image creator as well as other users. The refactory parts include: Move cache data retrieve methods out of Cache Data Fields Definition. Since this retrieve methods will be shared for both CoreRecipeInfo as well as the new introduced extra RecipeInfo in the following patches. (Bitbake rev: f0f53506926a3f79181796dde177f11f0a396b75) Signed-off-by: Liping Ke <liping.ke@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* siggen: don't choke with traceback when data is NoneChris Larson2011-06-071-3/+5
| | | | | | | | | | | | | Given we use bb.error, not bb.fatal, here, it seems this was intended to be non-fatal, yet we'd end up trying to concatenate None. Fix this by setting an empty task to the empty string, for the purposes of hashing. Also str() the value we get from the datastore, just in case something other than a string was stored there. (Bitbake rev: ec8a5a495b72e061a1e8d7c7449afb26581872c0) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* parse: pass a useful (if mangled) key to bb.data.expand for :=Chris Larson2011-06-071-1/+1
| | | | | | | (Bitbake rev: 8e1be0ca414d9d26e013ae212abdd9c39fa8df26) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* event: don't catch systemexit from handler executionChris Larson2011-06-021-1/+1
| | | | | | | | | | | | This means that anyone firing an event can get a systemexit and result in their process exiting, which isn't ideal, but behaves the way it used to (in particular, ensures that a sanity check failure will halt the build). This should be revisited in the future. (Bitbake rev: d6a0ffdd583be3df734171d7e91d334f798a79ce) Signed-off-by: Chris Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* data_smart: Adding overrides of zero length is pointless so lets notRichard Purdie2011-06-011-3/+4
| | | | | | (Bitbake rev: 67434496108efc3aba9cb1e3640bc712658b1408) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: use layer priority when applying bbappendsPaul Eggleton2011-06-011-10/+14
| | | | | | | | | | | | | If the priority of a layer has been specified with BBFILE_PRIORITY_ then use that to sort the list of BBFILES entries, which will affect the order in which .bbappend files are applied. Fixes [YOCTO #1125] (Bitbake rev: a8ab0af776ba20c83832215054180fbd15c274c0) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* providers.py: Correct PREFERRED_VERSION handlingRichard Purdie2011-06-011-2/+2
| | | | | | | | | | | | | | | | | Overrides on the right are the highest priority and in this case, pn-PN and PN should take priority over any other override so fix the code to do this. Also, since overrides will have been processed by bitbake, we shouldn't then be specifically looking up PREFERRED_VERSION_${PN} but just using PREFERRED_VERSION. This patch corrects the behaviours to match what the code is expected to do. (Bitbake rev: 606f1acc6fb8ccec45d6a52ed6ae6dc128011402) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/runqueue.py: Move BB_WORKERCONTEXT to a place where anonymous python ↵Richard Purdie2011-05-311-1/+2
| | | | | | can see it Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* fetch2/git: ensure network check log matches actual commandDarren Hart2011-05-271-6/+10
| | | | | | | | | | The git command string logged via check_network_access() does not match the actual command executed in a few places. Ensure that it does. (Bitbake rev: 10f3ca52dc274cd8b240987cfd7cd003aeda7ab1) Signed-off-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* fetch2/git: use logging.debug() and clarify messagesDarren Hart2011-05-271-2/+5
| | | | | | | | | | Replace a call to print() with logging.debug() and flesh out the message to clarify the state being reported. (Bitbake rev: 9a28f7744e2f4224e7c097b8c4c1d49731b9a47e) Signed-off-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/codeparser: Improve cache handlingRichard Purdie2011-05-272-10/+71
| | | | | | | | | | | | | | | | | | | The current codeparser cache handling hurts performance badly even over a couple of cores and certainly on many core systems, it can spent huge amounts of time in the codeparser cache save functions. This patch reworks the cache handling so that each parsing thread saves out its own "differences" file compared to any existing core cache and then the main bitbake thread picks these up and merges things back together. This was tested on systems with small and large numbers of cores and was found to perform orders of magnitude better in all cases despite the more complex code. (Bitbake rev: 9f27563d66523f5af1028f173d53ee75e0877d46) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/runqueue.py: Ensure existing setscene stamp files are taken into accountRichard Purdie2011-05-271-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | JaMa reported issues where bitbake would rebuild things instead of using the existing built tasks. This was tracked to a case where: a) rm_work is uses b) A depends on B c) B has a version change (e.g. PR bump) and A *and* B would then rebuild. It turns out that rm_work was correctly turning stamp files into the correct _setscene varients but bitbake was then ignoring them during setscene processing. If the correct sstate checksumed files didn't exist, everything would seemingly rebuild. The fix is to check for existing *_setscene stamps and if present, honour them. If "basichash" is enabled, the hash is included with the stamps so everything should then function as intended. (Bitbake rev: 0a4d857aabc86b973170ba9ce32b6b449a4e2165) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/utils.py: Add option to lockfiles to return immediately rather than waitRichard Purdie2011-05-271-1/+5
| | | | | | | | | There are usecases where we don't want to block waiting for a lockfile so enhance the lockfile handling functions to support this. (Bitbake rev: 97e8adf03e5fab1fd40c3d53c48f7b333bc2e145) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake/cooker.py: Ensure BBFILES is processed in orderRichard Purdie2011-05-271-3/+8
| | | | | | | | | | | | | | | The files found by collect_bbfiles should be processed in order but due to being processed using python's set(), the order was not being preserved. Use a list instead as whilst the code is slightly more ugly, order is preserved. Addresses [YOCTO #1100] Acked-by: Darren Hart <dvhart@linux.intel.com> (Bitbake rev: c12dd868368bdc3a4f800e075a30c67edca28d47) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-05-20 15:10:13 +0000