Holger Freyther [Sun, 17 May 2009 10:32:36 +0000 (12:32 +0200)]
[parser] Move the handling of a method to a function
We want to convert this into a proper AST. So move all
such operations to methods... Later change them to generate
a node... and create that node from here.
Holger Freyther [Sun, 17 May 2009 04:06:14 +0000 (06:06 +0200)]
[parser] Kill obtain/localpath from the parser
With obtain it was possible to use an existing fetcher to
download a bb or config file. In practive no one has used it
and it was likely broken in regard to depends_cache... Remove
it for now, simplfiy the code.
Robert P. J. Day [Sat, 16 Jan 2010 09:51:59 +0000 (04:51 -0500)]
Fix an obvious copy-and-paste error in the documentation for a
local fetch, and remove the option for a "patch" type URL, since
patches use a "file" type URL.
Richard Purdie [Sun, 22 Nov 2009 00:04:45 +0000 (00:04 +0000)]
fetch/git.py: BB_GIT_CLONE_FOR_SRCREV updates
Based on a patch from Martin Jansa <Martin.Jansa@gmail.com>:
* Add a _sortable_buildindex attribute and return the index separate from
the revision
* This means the git.py internal cache is no longer needed
* Adds the returned value to the cache so if the mechanism for
selecting the index changes, the values increase.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Martin Jansa [Tue, 17 Nov 2009 07:24:52 +0000 (08:24 +0100)]
Optional LOCALCOUNT for recipe
* Instead of autoincrement from persistent cache when srcrev is changed.
* Should be used by distributions with multiple builders, where consistent
PV is needed.
* Can be used instead of PR bump in PVs like this "0.0+${PR}+gitr${SRCPV}"
* BB_LOCALCOUNT_OVERRIDE to enable setting LOCALCOUNT for recipe
* This way LOCALCOUNTs can be specified directly in recipes instead of
separated distro config (as not all want to use them). And will be
used only when BB_LOCALCOUNT_OVERRIDE set in distro config.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
utils.py: add special handling for version delimiters
Make version comparison work properly for pre-releases and release-candidates,
when there is an extra suffix in the field, such as:
PV = "2.6.29+2.6.30-rc5-${PR}+gitr${SRCREV}"
More details: http://thread.gmane.org/gmane.comp.handhelds.openembedded/26691
Signed-off-by: Denys Dmytriyenko <denis@denix.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Chris Larson [Thu, 16 Jul 2009 17:49:49 +0000 (10:49 -0700)]
cache: only invalidate for non-existent depends if they used to exist.
Previously, if a file listed in the cached __depends did not exist, it would
always invalidate the cache. Now it only does so if the cached version
existed, and the current does not. In this way, we can support storing
entries in __depends for files which may or may not exist, and ensure that
creating such a file results in cache invalidation. Specifically, this is for
the amend.inc implementation.
Chris Larson [Thu, 10 Sep 2009 18:49:50 +0000 (11:49 -0700)]
Only print python exception tracebacks if debugging is enabled.
Uses sys.excepthook to replace the toplevel exception handler with a version
that obeys the debug level of the 'default' messaging domain. A non-zero
value there will result in displaying the full traceback.
Chris Larson [Thu, 27 Aug 2009 19:20:10 +0000 (12:20 -0700)]
daemonize: Kill the forcing of umask to 0 in our children.
It forces the daemon umask to the module level UMASK variable, which defaults
to 0, so the bitbake daemons end up with a umask of 0. Fixed by setting UMASK
to None and making it only run umask when it's not None, so our children will
inherit the parent umask
Chris Larson [Thu, 23 Jul 2009 17:44:55 +0000 (10:44 -0700)]
Update the minimal base.bbclass & bitbake.conf.
I could argue in favor of the removal of these entirely, as their usefulness
is limited, and I've yet to see anyone use bitbake for anything without using
OE as a base. It's something to consider, anyway, but this at least makes
them parse without complaining.
At present there is a bottleneck in runqueue in the
get_recursive_tdepends() function which bothers me as we never used to
have it. It appeared when we fixed some correctness issues with the
dependency tree and the code in this area has grown adhoc for too long.
As an example the above function was getting called 500,000 times in my
main test case of building an image. Its particularly problematic in
builds with many recursive dependencies such as 'bitbake world'.
This commit rewrites the problematic function entirely with the
following benefits:
* Replaces the most illegible code in that function with code thats
easier to understand
* Builds the dependency tree per filename, not per task since we don't
need it per task which is a performance win
* Improves the documentation in places
* Much faster execution
* Reuses the main dependency tree data, doesn't make its own.
The code functions very differently to the original. Previously the
recursive dependency tree and the main dependency tree were separate. In
this implementation we use the main tree to build the recursive tree
after the main tree has been completed, then inject the dependencies.
Compared with the original this actually inserts small numbers (4 in my
test cases) of additional dependencies into the task graph such as
image_recipe:do_rootfs -> image_recipe:do_package_write_ipk which is
arguably an bug in the existing implementation. I've checked into this,
understand why its happening and believe none of the additional
dependencies should cause any complications.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Richard Purdie [Thu, 23 Jul 2009 16:53:32 +0000 (17:53 +0100)]
cooker.py: Improve server idle handling (from Poky)
This patch:
* Uses the xmlrpc timeout controls added in python 2.6 removing the need to
hack the class instead. The hacking didn't work for 2.6.
* Converts the parsing function to parse a file per call to the function
* Allows checking for xmlrpc commands between parsing files allowing the user
to interrupt parsing.
* Starts to teach the command queue about command properties such as whether
they require the cache.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>