Chris Larson [Fri, 10 Sep 2010 18:14:54 +0000 (11:14 -0700)]
Fix exit code display for task failure
Per the python documentation, os.waitpid returns the exitcode shifted up by 8
bits, and we weren't compensating, resulting in a display of 'failed with 256'
when a worker process exits with a code of 1.
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Chris Larson [Thu, 4 Nov 2010 15:47:11 +0000 (08:47 -0700)]
Fix GraphViz .dot output for rdepends and rrecs
Use bb.utils.explode_deps to break up the rdepends and rrecommends strings.
This fixes the same issue which was fixed by a number of patches floating
around, but uses explode_deps rather than regular expressions.
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Eric BENARD [Mon, 6 Sep 2010 08:51:52 +0000 (08:51 +0000)]
bitbake: lib/bb/fetch/hg: fix fetching from a mercurial repository
* without this fix, we get :
updating working directory
74 files updated, 0 files merged, 0 files removed, 0 files unresolved
abort: There is no Mercurial repository here (.hg not found)!
Signed-off-by: Eric Bénard <eric@eukrea.com> Tested-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Joshua Lock [Tue, 5 Oct 2010 11:44:08 +0000 (12:44 +0100)]
fetch: if mirror fetching fails, ensure exception is raised
We catch any exception raised by the fetchers go() method and attempt to work
around it by trying any (post) mirrors which are configured. However, should
the mirrors fail the exception is lost and the fetch is assumed to have
completed successfully.
Instead, save the exception and if the local file does not exist after trying
the mirrors re-raise the exception.
Fixes poky [BUGID #362]
Signed-off-by: Joshua Lock <josh@linux.intel.com> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Jeff Dike [Tue, 29 Jun 2010 12:33:24 +0000 (13:33 +0100)]
create cooker object after cleaning the environment
Previously, the cooker object was created before the environment was
cleaned, saving everything that was in the environment and dumping
into the run scripts.
The patch ensures that the cooker gets a cleaned environment when it's
created.
Chris Larson [Wed, 31 Mar 2010 03:06:07 +0000 (20:06 -0700)]
Consolidate the exec/eval bits, switch anonfunc to better_exec, etc
The methodpool, ${@} expansions, anonymous python functions, event handlers
now all run with the same global context, ensuring a consistent environment
for them. Added a bb.utils.better_eval function which does an eval() with the
same globals as better_exec.
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Chris Larson [Tue, 30 Mar 2010 23:21:23 +0000 (16:21 -0700)]
Two minor changes to the way python snippet expansion happens
- Use a single dictionary for the context, both global & local, since for some
reason it chokes wanting a global "d" rather than a local in the metadata.
- First compile the string into a code object before running eval, so we can
include the variable name in an evaluation error.
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Chris Larson [Wed, 24 Mar 2010 16:21:53 +0000 (09:21 -0700)]
bb.utils: remove old portage remnants
The following utility functions were removed. Note that in this particular
case we're bypassing a proper deprecation process, as these functions are
clearly not utilized, are obvious remnants of old ways of doing things, and
some of which do not even function properly.
Chris Larson [Sat, 20 Mar 2010 00:22:19 +0000 (17:22 -0700)]
Implement BBVERSIONS
This implements a feature similar to BBCLASSEXTEND, but for generating
multiple versions of a given recipe. For example: BBVERSIONS = "1.0 2.0 git".
In addition to the above, one can utilize [a-b] style patterns, and can have a
:<basever> postfix, which allows you to essentially name the range of
versions. Both the current version and the basever end up in OVERRIDES, and
the basever gets placed into the BPV variable. The default BPV, if none is
specified, is the original PV of the recipe, before bbversions processing.
In this way, you can do things like:
BBVERSIONS = "1.0.[0-6]:1.0.0+
1.0.[7-9]:1.0.7+"
Enrico Scholz [Sun, 21 Mar 2010 22:25:25 +0000 (23:25 +0100)]
Expand PREMIRRORS
When not expanding PREMIRRORS, the functions fails/does not work correctly
when PREMIRRORS is not a plain string (e.g. contains ${...} or a ${@...}
statements).
Signed-off-by: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de> Signed-off-by: Chris Larson <clarson@kergoth.com>
This prevents a misleading backtrace:
ERROR: no files to build.
Command execution failed: Traceback (most recent call last):
File ".../bitbake/build/lib/bb/command.py", line 83, in runAsyncCommand
self.cooker.updateCache()
File ".../bitbake/build/lib/bb/cooker.py", line 779, in updateCache
if not self.parser.parse_next():
File ".../bitbake/build/lib/bb/cooker.py", line 969, in parse_next
cooker.bb_cache.sync()
UnboundLocalError: local variable 'cooker' referenced before assignment
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> Signed-off-by: Chris Larson <clarson@kergoth.com>
Chris Larson [Thu, 25 Feb 2010 16:42:28 +0000 (09:42 -0700)]
Implement ??= operator
??= is a lazy, conditional assignment. Whereas a ?= immediately assigns to
the variable if the variable has not yet been set, ??= does not apply the
default assignment until the end of the parse. As a result, the final ??= for
a given variable is used, as opposed to the first as in ?=.
Note that the initial implementation relies upon finalise() to apply the
defaults, so a "bitbake -e" without specifying a recipe will not show the
defaults as set by ??=. Moving application of the default into getVar adds
too large a performance hit. We may want to revisit this later.
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Chris Larson [Thu, 11 Jun 2009 20:10:04 +0000 (13:10 -0700)]
Avoid unnecessary calls to keys() when iterating over dictionaries.
dict objects provide an __iter__ method for the iteration which gives you the
keys, so calling keys directly is unnecessary, and isn't really a best
practice. The only time you really need to call the keys is if there's a
danger of the dict changing out from underneith you, either due to external
forces or due to modification of the iterable in the loop. Iterations over
os.environ are apparently subject to such changes, so they must continue to
use keys().
As an aside, also switches a couple spots to using sorted() rather than
creating a temporary list with keys() and sorting that.
Chris Larson [Tue, 23 Feb 2010 18:55:43 +0000 (11:55 -0700)]
Re-getVar BBCLASSEXTEND after finalise()
This ensures that an anonymous python function is able to manipulate the
BBCLASSEXTEND contents, and, therefore, amend.inc files are able to add to it.
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Chris Larson [Fri, 19 Feb 2010 23:26:33 +0000 (16:26 -0700)]
Error early if BBPATH is unset, rather than falling back to share/bitbake
Better to error as early as possible rather than experience strange behavior
resulting from the use of the largely useless stock bitbake.conf/base.bbclass.
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Martyn Welch [Tue, 26 Jan 2010 14:35:51 +0000 (14:35 +0000)]
Add FETCHCMD parameter for git
The Git fetcher currently hardwires the git command to "git". Allow the
path and any additional wrappers to the Git command to be provided via
FETCHCMD functionality, as with some of the other fetchers.
If FETCHCMD_git is not define in bitbake.conf, the fetcher defaults to "git".
Joshua Lock [Fri, 5 Feb 2010 12:08:15 +0000 (12:08 +0000)]
Test premirrors and mirrors in checkstatus()
checkstatus() is used to ensure we can fetch a copy of each file, so it makes
sense to also test PREMIRRORS and MIRRORS in the method.
This patch adds calls to try_mirrors() to the Fetch.checkstatus() method and
changes the try_mirrors() method to take a check argument, which is False by
default. When check is True try_mirrors() will call a fetchers checkstatus()
with the replaced uri.
Joshua Lock [Wed, 3 Feb 2010 16:08:09 +0000 (16:08 +0000)]
if PREMIRRORS set test for local file in FetchData.setup_localpath
When we are using PREMIRRORS it's possible a mirror in the local namespace
(some filesystem path, i.e. an NFS share) provides read-only files.
This is a perfectly valid scenario so this patch fixes bitbake so that for
such a scenario locapath is set to the files path rather than some child
of DL_DIR.
Joshua Lock [Tue, 2 Feb 2010 17:57:20 +0000 (17:57 +0000)]
Enhance the fetchers' support for local mirrors
Modify the try_mirrors() function to return the localpath of the fetched file
and update the data dictionary to reflect this.
Secondly the metadata files, lock and md5, should always be stored relative to
the ${DL_DIR} as it is possible that the localpath is a read-only directory,
for example in the scenario where there is a read-only file:// mirror.
Joshua Lock [Mon, 1 Feb 2010 16:56:16 +0000 (16:56 +0000)]
unify mirror support and make it independant of the fetcher
This patch serves two purposes. Firstly it unifies the concept of mirrors into
PREMIRRORS and MIRRORS. PREMIRRORS are tried before the SRC_URI defined in the
recipe whereas MIRRORS are tried only if that fails.
The tarball stash was conceptually inline with a PREMIRROR only with special
handling within the wget fetcher and therefore only worked with certain
fetch types.
Secondly the patch removes the need for individual fetch implementations to
worry about mirror handling.
With this patch, the base fetch implementation will first try to use a
PREMIRROR to fetch the desired object, if this fails the native fetch method
for the object will be tried and if this fails will try to fetch a copy from
one of the MIRRORS.
Holger Freyther [Tue, 19 May 2009 11:59:50 +0000 (13:59 +0200)]
[parser] Make resolve_file only resolve the path
Do not attempt to open the file in the resolve_file method
(a lot like bb.which... maybe bb.which can be used). This way
we don't need to open/close a file which we have already parsed.
Holger Freyther [Tue, 19 May 2009 11:22:30 +0000 (13:22 +0200)]
[parser] prepare to cache some .bbcclass and .inc files
Our parser is shit but instead to replace it now we will see
how long we can drive the wave by caching parsed files. This
will not go through the feeder again but we can just reevaluate
the StatementGroup.
Holger Freyther [Tue, 19 May 2009 10:10:37 +0000 (12:10 +0200)]
[parser] Remove the "data" from feeder, evaluate after parsing a file
Evaluate the statements after having parsed one file. This is
referred to as "entwirren" and we can remove the direct evaluation
and postpone a bit, in the future we can use a cached copy instead
of parsing the original.
Holger Freyther [Mon, 18 May 2009 17:24:07 +0000 (19:24 +0200)]
[parser] Cary a Statement Node through the parsing
When parsing we will collect a number of statements
that can be evaluated...The plan is to be evaluate
things twice (old+new) and then compare the result,
it should be the same.
projects / thirdparty / openembedded / openembedded-core-contrib.git / log
