2010-02-12 14:14:49 +00:00
|
|
|
# ex:ts=4:sw=4:sts=4:et
|
|
|
|
# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
|
|
|
|
"""
|
|
|
|
AbstractSyntaxTree classes for the Bitbake language
|
|
|
|
"""
|
|
|
|
|
|
|
|
# Copyright (C) 2003, 2004 Chris Larson
|
|
|
|
# Copyright (C) 2003, 2004 Phil Blundell
|
|
|
|
# Copyright (C) 2009 Holger Hans Peter Freyther
|
|
|
|
#
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License version 2 as
|
|
|
|
# published by the Free Software Foundation.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License along
|
|
|
|
# with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
|
|
|
|
|
2010-06-20 19:07:34 +00:00
|
|
|
from __future__ import absolute_import
|
|
|
|
from future_builtins import filter
|
2010-06-10 17:35:31 +00:00
|
|
|
import re
|
|
|
|
import string
|
|
|
|
import logging
|
|
|
|
import bb
|
2010-06-20 19:08:07 +00:00
|
|
|
import itertools
|
2010-06-10 17:35:31 +00:00
|
|
|
from bb import methodpool
|
|
|
|
from bb.parse import logger
|
2010-02-12 14:14:49 +00:00
|
|
|
|
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+"
SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1"
Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb.
(Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-20 00:22:19 +00:00
|
|
|
_bbversions_re = re.compile(r"\[(?P<from>[0-9]+)-(?P<to>[0-9]+)\]")
|
2010-02-12 14:14:49 +00:00
|
|
|
|
2009-07-21 19:00:29 +00:00
|
|
|
class StatementGroup(list):
|
2009-05-18 17:24:07 +00:00
|
|
|
def eval(self, data):
|
2010-06-20 19:08:07 +00:00
|
|
|
for statement in self:
|
|
|
|
statement.eval(data)
|
2009-05-18 17:24:07 +00:00
|
|
|
|
2009-07-21 19:00:29 +00:00
|
|
|
class AstNode(object):
|
2011-01-04 20:34:08 +00:00
|
|
|
def __init__(self, filename, lineno):
|
|
|
|
self.filename = filename
|
|
|
|
self.lineno = lineno
|
2009-05-19 07:37:07 +00:00
|
|
|
|
2009-07-21 19:00:29 +00:00
|
|
|
class IncludeNode(AstNode):
|
2011-01-04 20:34:08 +00:00
|
|
|
def __init__(self, filename, lineno, what_file, force):
|
|
|
|
AstNode.__init__(self, filename, lineno)
|
2009-05-18 17:50:14 +00:00
|
|
|
self.what_file = what_file
|
2010-02-12 14:41:28 +00:00
|
|
|
self.force = force
|
2009-05-18 17:50:14 +00:00
|
|
|
|
|
|
|
def eval(self, data):
|
|
|
|
"""
|
|
|
|
Include the file and evaluate the statements
|
|
|
|
"""
|
2011-11-25 14:57:53 +00:00
|
|
|
s = data.expand(self.what_file)
|
2011-01-04 20:34:08 +00:00
|
|
|
logger.debug(2, "CONF %s:%s: including %s", self.filename, self.lineno, s)
|
2009-05-18 17:50:14 +00:00
|
|
|
|
2009-05-19 10:10:37 +00:00
|
|
|
# TODO: Cache those includes... maybe not here though
|
2010-02-12 17:45:51 +00:00
|
|
|
if self.force:
|
2012-02-23 17:38:08 +00:00
|
|
|
bb.parse.ConfHandler.include(self.filename, s, self.lineno, data, "include required")
|
2010-02-12 14:41:28 +00:00
|
|
|
else:
|
2012-02-23 17:38:08 +00:00
|
|
|
bb.parse.ConfHandler.include(self.filename, s, self.lineno, data, False)
|
2009-05-18 17:50:14 +00:00
|
|
|
|
2009-07-21 19:00:29 +00:00
|
|
|
class ExportNode(AstNode):
|
2011-01-04 20:34:08 +00:00
|
|
|
def __init__(self, filename, lineno, var):
|
|
|
|
AstNode.__init__(self, filename, lineno)
|
2009-05-18 17:50:14 +00:00
|
|
|
self.var = var
|
|
|
|
|
|
|
|
def eval(self, data):
|
bitbake: bitbake: data_smart.py and friends: Track variable history
This patch adds tracking of the history of variable assignments.
The changes are predominantly localized to data_smart.py and
parse/ast.py. cooker.py and data.py are altered to display the
recorded data, and turn tracking on for the bitbake -e case.
The data.py update_data() function warns DataSmart.finalize()
to report the caller one further back up the tree.
In general, d.setVar() does what it used to do. Optionally,
arguments describing an operation may be appended; if none
are present, the operation is implicitly ignored. If it's
not ignored, it will attempt to infer missing information
(name of variable, value assigned, file and line) by examining
the traceback. This slightly elaborate process eliminates a
category of problems in which the 'var' member of the keyword
arguments dict is set, and a positional argument corresponding
to 'var' is also set. It also makes calling much simpler for
the common cases.
The resulting output gives you a pretty good picture of what
values got set, and how they got set.
RP Modifications:
a) Split from IncludeHistory to separate VariableHistory
b) Add dedicated copy function instead of deepcopy
c) Use COW for variables dict
d) Remove 'value' loginfo value and just use 'details'
e) Desensitise code for calling order (set 'op' before/after
infer_caller_details was error prone)
f) Fix bug where ?= "" wasn't shown correctly
g) Log more set operations as some variables mysteriously acquired
values previously
h) Standardise infer_caller_details to be triggered from .record()
where at all possible to reduce overhead in non-enabled cases
i) Rename variable parameter names to match inference code
j) Add VariableHistory emit() function to match IncludeHistory
k) Fix handling of appendVar, prependVar and matching flag ops
l) Use ignored=True to stop logging further events where appropriate
(Bitbake rev: f00524a3729000cbcb3317fee933ac448fae5e2d)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-18 11:47:34 +00:00
|
|
|
data.setVarFlag(self.var, "export", 1, op = 'exported')
|
2009-05-18 17:50:14 +00:00
|
|
|
|
2009-07-21 19:00:29 +00:00
|
|
|
class DataNode(AstNode):
|
2009-05-18 17:50:14 +00:00
|
|
|
"""
|
|
|
|
Various data related updates. For the sake of sanity
|
|
|
|
we have one class doing all this. This means that all
|
|
|
|
this need to be re-evaluated... we might be able to do
|
|
|
|
that faster with multiple classes.
|
|
|
|
"""
|
2011-01-04 20:34:08 +00:00
|
|
|
def __init__(self, filename, lineno, groupd):
|
|
|
|
AstNode.__init__(self, filename, lineno)
|
2009-05-18 17:50:14 +00:00
|
|
|
self.groupd = groupd
|
|
|
|
|
2009-05-18 18:03:50 +00:00
|
|
|
def getFunc(self, key, data):
|
|
|
|
if 'flag' in self.groupd and self.groupd['flag'] != None:
|
2011-07-05 10:02:04 +00:00
|
|
|
return data.getVarFlag(key, self.groupd['flag'], noweakdefault=True)
|
2009-05-18 18:03:50 +00:00
|
|
|
else:
|
2011-07-05 10:02:04 +00:00
|
|
|
return data.getVar(key, noweakdefault=True)
|
2009-05-18 18:03:50 +00:00
|
|
|
|
2009-05-18 17:50:14 +00:00
|
|
|
def eval(self, data):
|
|
|
|
groupd = self.groupd
|
|
|
|
key = groupd["var"]
|
bitbake: bitbake: data_smart.py and friends: Track variable history
This patch adds tracking of the history of variable assignments.
The changes are predominantly localized to data_smart.py and
parse/ast.py. cooker.py and data.py are altered to display the
recorded data, and turn tracking on for the bitbake -e case.
The data.py update_data() function warns DataSmart.finalize()
to report the caller one further back up the tree.
In general, d.setVar() does what it used to do. Optionally,
arguments describing an operation may be appended; if none
are present, the operation is implicitly ignored. If it's
not ignored, it will attempt to infer missing information
(name of variable, value assigned, file and line) by examining
the traceback. This slightly elaborate process eliminates a
category of problems in which the 'var' member of the keyword
arguments dict is set, and a positional argument corresponding
to 'var' is also set. It also makes calling much simpler for
the common cases.
The resulting output gives you a pretty good picture of what
values got set, and how they got set.
RP Modifications:
a) Split from IncludeHistory to separate VariableHistory
b) Add dedicated copy function instead of deepcopy
c) Use COW for variables dict
d) Remove 'value' loginfo value and just use 'details'
e) Desensitise code for calling order (set 'op' before/after
infer_caller_details was error prone)
f) Fix bug where ?= "" wasn't shown correctly
g) Log more set operations as some variables mysteriously acquired
values previously
h) Standardise infer_caller_details to be triggered from .record()
where at all possible to reduce overhead in non-enabled cases
i) Rename variable parameter names to match inference code
j) Add VariableHistory emit() function to match IncludeHistory
k) Fix handling of appendVar, prependVar and matching flag ops
l) Use ignored=True to stop logging further events where appropriate
(Bitbake rev: f00524a3729000cbcb3317fee933ac448fae5e2d)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-18 11:47:34 +00:00
|
|
|
loginfo = {
|
|
|
|
'variable': key,
|
|
|
|
'file': self.filename,
|
|
|
|
'line': self.lineno,
|
|
|
|
}
|
2009-05-18 17:50:14 +00:00
|
|
|
if "exp" in groupd and groupd["exp"] != None:
|
bitbake: bitbake: data_smart.py and friends: Track variable history
This patch adds tracking of the history of variable assignments.
The changes are predominantly localized to data_smart.py and
parse/ast.py. cooker.py and data.py are altered to display the
recorded data, and turn tracking on for the bitbake -e case.
The data.py update_data() function warns DataSmart.finalize()
to report the caller one further back up the tree.
In general, d.setVar() does what it used to do. Optionally,
arguments describing an operation may be appended; if none
are present, the operation is implicitly ignored. If it's
not ignored, it will attempt to infer missing information
(name of variable, value assigned, file and line) by examining
the traceback. This slightly elaborate process eliminates a
category of problems in which the 'var' member of the keyword
arguments dict is set, and a positional argument corresponding
to 'var' is also set. It also makes calling much simpler for
the common cases.
The resulting output gives you a pretty good picture of what
values got set, and how they got set.
RP Modifications:
a) Split from IncludeHistory to separate VariableHistory
b) Add dedicated copy function instead of deepcopy
c) Use COW for variables dict
d) Remove 'value' loginfo value and just use 'details'
e) Desensitise code for calling order (set 'op' before/after
infer_caller_details was error prone)
f) Fix bug where ?= "" wasn't shown correctly
g) Log more set operations as some variables mysteriously acquired
values previously
h) Standardise infer_caller_details to be triggered from .record()
where at all possible to reduce overhead in non-enabled cases
i) Rename variable parameter names to match inference code
j) Add VariableHistory emit() function to match IncludeHistory
k) Fix handling of appendVar, prependVar and matching flag ops
l) Use ignored=True to stop logging further events where appropriate
(Bitbake rev: f00524a3729000cbcb3317fee933ac448fae5e2d)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-18 11:47:34 +00:00
|
|
|
data.setVarFlag(key, "export", 1, op = 'exported', **loginfo)
|
|
|
|
|
|
|
|
op = "set"
|
2009-05-18 17:50:14 +00:00
|
|
|
if "ques" in groupd and groupd["ques"] != None:
|
2009-05-18 18:03:50 +00:00
|
|
|
val = self.getFunc(key, data)
|
bitbake: bitbake: data_smart.py and friends: Track variable history
This patch adds tracking of the history of variable assignments.
The changes are predominantly localized to data_smart.py and
parse/ast.py. cooker.py and data.py are altered to display the
recorded data, and turn tracking on for the bitbake -e case.
The data.py update_data() function warns DataSmart.finalize()
to report the caller one further back up the tree.
In general, d.setVar() does what it used to do. Optionally,
arguments describing an operation may be appended; if none
are present, the operation is implicitly ignored. If it's
not ignored, it will attempt to infer missing information
(name of variable, value assigned, file and line) by examining
the traceback. This slightly elaborate process eliminates a
category of problems in which the 'var' member of the keyword
arguments dict is set, and a positional argument corresponding
to 'var' is also set. It also makes calling much simpler for
the common cases.
The resulting output gives you a pretty good picture of what
values got set, and how they got set.
RP Modifications:
a) Split from IncludeHistory to separate VariableHistory
b) Add dedicated copy function instead of deepcopy
c) Use COW for variables dict
d) Remove 'value' loginfo value and just use 'details'
e) Desensitise code for calling order (set 'op' before/after
infer_caller_details was error prone)
f) Fix bug where ?= "" wasn't shown correctly
g) Log more set operations as some variables mysteriously acquired
values previously
h) Standardise infer_caller_details to be triggered from .record()
where at all possible to reduce overhead in non-enabled cases
i) Rename variable parameter names to match inference code
j) Add VariableHistory emit() function to match IncludeHistory
k) Fix handling of appendVar, prependVar and matching flag ops
l) Use ignored=True to stop logging further events where appropriate
(Bitbake rev: f00524a3729000cbcb3317fee933ac448fae5e2d)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-18 11:47:34 +00:00
|
|
|
op = "set?"
|
2009-05-18 17:50:14 +00:00
|
|
|
if val == None:
|
|
|
|
val = groupd["value"]
|
|
|
|
elif "colon" in groupd and groupd["colon"] != None:
|
|
|
|
e = data.createCopy()
|
|
|
|
bb.data.update_data(e)
|
bitbake: bitbake: data_smart.py and friends: Track variable history
This patch adds tracking of the history of variable assignments.
The changes are predominantly localized to data_smart.py and
parse/ast.py. cooker.py and data.py are altered to display the
recorded data, and turn tracking on for the bitbake -e case.
The data.py update_data() function warns DataSmart.finalize()
to report the caller one further back up the tree.
In general, d.setVar() does what it used to do. Optionally,
arguments describing an operation may be appended; if none
are present, the operation is implicitly ignored. If it's
not ignored, it will attempt to infer missing information
(name of variable, value assigned, file and line) by examining
the traceback. This slightly elaborate process eliminates a
category of problems in which the 'var' member of the keyword
arguments dict is set, and a positional argument corresponding
to 'var' is also set. It also makes calling much simpler for
the common cases.
The resulting output gives you a pretty good picture of what
values got set, and how they got set.
RP Modifications:
a) Split from IncludeHistory to separate VariableHistory
b) Add dedicated copy function instead of deepcopy
c) Use COW for variables dict
d) Remove 'value' loginfo value and just use 'details'
e) Desensitise code for calling order (set 'op' before/after
infer_caller_details was error prone)
f) Fix bug where ?= "" wasn't shown correctly
g) Log more set operations as some variables mysteriously acquired
values previously
h) Standardise infer_caller_details to be triggered from .record()
where at all possible to reduce overhead in non-enabled cases
i) Rename variable parameter names to match inference code
j) Add VariableHistory emit() function to match IncludeHistory
k) Fix handling of appendVar, prependVar and matching flag ops
l) Use ignored=True to stop logging further events where appropriate
(Bitbake rev: f00524a3729000cbcb3317fee933ac448fae5e2d)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-18 11:47:34 +00:00
|
|
|
op = "immediate"
|
2011-11-25 14:57:53 +00:00
|
|
|
val = e.expand(groupd["value"], key + "[:=]")
|
2009-05-18 17:50:14 +00:00
|
|
|
elif "append" in groupd and groupd["append"] != None:
|
bitbake: bitbake: data_smart.py and friends: Track variable history
This patch adds tracking of the history of variable assignments.
The changes are predominantly localized to data_smart.py and
parse/ast.py. cooker.py and data.py are altered to display the
recorded data, and turn tracking on for the bitbake -e case.
The data.py update_data() function warns DataSmart.finalize()
to report the caller one further back up the tree.
In general, d.setVar() does what it used to do. Optionally,
arguments describing an operation may be appended; if none
are present, the operation is implicitly ignored. If it's
not ignored, it will attempt to infer missing information
(name of variable, value assigned, file and line) by examining
the traceback. This slightly elaborate process eliminates a
category of problems in which the 'var' member of the keyword
arguments dict is set, and a positional argument corresponding
to 'var' is also set. It also makes calling much simpler for
the common cases.
The resulting output gives you a pretty good picture of what
values got set, and how they got set.
RP Modifications:
a) Split from IncludeHistory to separate VariableHistory
b) Add dedicated copy function instead of deepcopy
c) Use COW for variables dict
d) Remove 'value' loginfo value and just use 'details'
e) Desensitise code for calling order (set 'op' before/after
infer_caller_details was error prone)
f) Fix bug where ?= "" wasn't shown correctly
g) Log more set operations as some variables mysteriously acquired
values previously
h) Standardise infer_caller_details to be triggered from .record()
where at all possible to reduce overhead in non-enabled cases
i) Rename variable parameter names to match inference code
j) Add VariableHistory emit() function to match IncludeHistory
k) Fix handling of appendVar, prependVar and matching flag ops
l) Use ignored=True to stop logging further events where appropriate
(Bitbake rev: f00524a3729000cbcb3317fee933ac448fae5e2d)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-18 11:47:34 +00:00
|
|
|
op = "append"
|
2009-05-18 18:03:50 +00:00
|
|
|
val = "%s %s" % ((self.getFunc(key, data) or ""), groupd["value"])
|
2009-05-18 17:50:14 +00:00
|
|
|
elif "prepend" in groupd and groupd["prepend"] != None:
|
bitbake: bitbake: data_smart.py and friends: Track variable history
This patch adds tracking of the history of variable assignments.
The changes are predominantly localized to data_smart.py and
parse/ast.py. cooker.py and data.py are altered to display the
recorded data, and turn tracking on for the bitbake -e case.
The data.py update_data() function warns DataSmart.finalize()
to report the caller one further back up the tree.
In general, d.setVar() does what it used to do. Optionally,
arguments describing an operation may be appended; if none
are present, the operation is implicitly ignored. If it's
not ignored, it will attempt to infer missing information
(name of variable, value assigned, file and line) by examining
the traceback. This slightly elaborate process eliminates a
category of problems in which the 'var' member of the keyword
arguments dict is set, and a positional argument corresponding
to 'var' is also set. It also makes calling much simpler for
the common cases.
The resulting output gives you a pretty good picture of what
values got set, and how they got set.
RP Modifications:
a) Split from IncludeHistory to separate VariableHistory
b) Add dedicated copy function instead of deepcopy
c) Use COW for variables dict
d) Remove 'value' loginfo value and just use 'details'
e) Desensitise code for calling order (set 'op' before/after
infer_caller_details was error prone)
f) Fix bug where ?= "" wasn't shown correctly
g) Log more set operations as some variables mysteriously acquired
values previously
h) Standardise infer_caller_details to be triggered from .record()
where at all possible to reduce overhead in non-enabled cases
i) Rename variable parameter names to match inference code
j) Add VariableHistory emit() function to match IncludeHistory
k) Fix handling of appendVar, prependVar and matching flag ops
l) Use ignored=True to stop logging further events where appropriate
(Bitbake rev: f00524a3729000cbcb3317fee933ac448fae5e2d)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-18 11:47:34 +00:00
|
|
|
op = "prepend"
|
2009-05-18 18:03:50 +00:00
|
|
|
val = "%s %s" % (groupd["value"], (self.getFunc(key, data) or ""))
|
2009-05-18 17:50:14 +00:00
|
|
|
elif "postdot" in groupd and groupd["postdot"] != None:
|
bitbake: bitbake: data_smart.py and friends: Track variable history
This patch adds tracking of the history of variable assignments.
The changes are predominantly localized to data_smart.py and
parse/ast.py. cooker.py and data.py are altered to display the
recorded data, and turn tracking on for the bitbake -e case.
The data.py update_data() function warns DataSmart.finalize()
to report the caller one further back up the tree.
In general, d.setVar() does what it used to do. Optionally,
arguments describing an operation may be appended; if none
are present, the operation is implicitly ignored. If it's
not ignored, it will attempt to infer missing information
(name of variable, value assigned, file and line) by examining
the traceback. This slightly elaborate process eliminates a
category of problems in which the 'var' member of the keyword
arguments dict is set, and a positional argument corresponding
to 'var' is also set. It also makes calling much simpler for
the common cases.
The resulting output gives you a pretty good picture of what
values got set, and how they got set.
RP Modifications:
a) Split from IncludeHistory to separate VariableHistory
b) Add dedicated copy function instead of deepcopy
c) Use COW for variables dict
d) Remove 'value' loginfo value and just use 'details'
e) Desensitise code for calling order (set 'op' before/after
infer_caller_details was error prone)
f) Fix bug where ?= "" wasn't shown correctly
g) Log more set operations as some variables mysteriously acquired
values previously
h) Standardise infer_caller_details to be triggered from .record()
where at all possible to reduce overhead in non-enabled cases
i) Rename variable parameter names to match inference code
j) Add VariableHistory emit() function to match IncludeHistory
k) Fix handling of appendVar, prependVar and matching flag ops
l) Use ignored=True to stop logging further events where appropriate
(Bitbake rev: f00524a3729000cbcb3317fee933ac448fae5e2d)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-18 11:47:34 +00:00
|
|
|
op = "postdot"
|
2009-05-18 18:03:50 +00:00
|
|
|
val = "%s%s" % ((self.getFunc(key, data) or ""), groupd["value"])
|
2009-05-18 17:50:14 +00:00
|
|
|
elif "predot" in groupd and groupd["predot"] != None:
|
bitbake: bitbake: data_smart.py and friends: Track variable history
This patch adds tracking of the history of variable assignments.
The changes are predominantly localized to data_smart.py and
parse/ast.py. cooker.py and data.py are altered to display the
recorded data, and turn tracking on for the bitbake -e case.
The data.py update_data() function warns DataSmart.finalize()
to report the caller one further back up the tree.
In general, d.setVar() does what it used to do. Optionally,
arguments describing an operation may be appended; if none
are present, the operation is implicitly ignored. If it's
not ignored, it will attempt to infer missing information
(name of variable, value assigned, file and line) by examining
the traceback. This slightly elaborate process eliminates a
category of problems in which the 'var' member of the keyword
arguments dict is set, and a positional argument corresponding
to 'var' is also set. It also makes calling much simpler for
the common cases.
The resulting output gives you a pretty good picture of what
values got set, and how they got set.
RP Modifications:
a) Split from IncludeHistory to separate VariableHistory
b) Add dedicated copy function instead of deepcopy
c) Use COW for variables dict
d) Remove 'value' loginfo value and just use 'details'
e) Desensitise code for calling order (set 'op' before/after
infer_caller_details was error prone)
f) Fix bug where ?= "" wasn't shown correctly
g) Log more set operations as some variables mysteriously acquired
values previously
h) Standardise infer_caller_details to be triggered from .record()
where at all possible to reduce overhead in non-enabled cases
i) Rename variable parameter names to match inference code
j) Add VariableHistory emit() function to match IncludeHistory
k) Fix handling of appendVar, prependVar and matching flag ops
l) Use ignored=True to stop logging further events where appropriate
(Bitbake rev: f00524a3729000cbcb3317fee933ac448fae5e2d)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-18 11:47:34 +00:00
|
|
|
op = "predot"
|
2009-05-18 18:03:50 +00:00
|
|
|
val = "%s%s" % (groupd["value"], (self.getFunc(key, data) or ""))
|
2009-05-18 17:50:14 +00:00
|
|
|
else:
|
|
|
|
val = groupd["value"]
|
2010-02-25 16:42:28 +00:00
|
|
|
|
bitbake: bitbake: data_smart.py and friends: Track variable history
This patch adds tracking of the history of variable assignments.
The changes are predominantly localized to data_smart.py and
parse/ast.py. cooker.py and data.py are altered to display the
recorded data, and turn tracking on for the bitbake -e case.
The data.py update_data() function warns DataSmart.finalize()
to report the caller one further back up the tree.
In general, d.setVar() does what it used to do. Optionally,
arguments describing an operation may be appended; if none
are present, the operation is implicitly ignored. If it's
not ignored, it will attempt to infer missing information
(name of variable, value assigned, file and line) by examining
the traceback. This slightly elaborate process eliminates a
category of problems in which the 'var' member of the keyword
arguments dict is set, and a positional argument corresponding
to 'var' is also set. It also makes calling much simpler for
the common cases.
The resulting output gives you a pretty good picture of what
values got set, and how they got set.
RP Modifications:
a) Split from IncludeHistory to separate VariableHistory
b) Add dedicated copy function instead of deepcopy
c) Use COW for variables dict
d) Remove 'value' loginfo value and just use 'details'
e) Desensitise code for calling order (set 'op' before/after
infer_caller_details was error prone)
f) Fix bug where ?= "" wasn't shown correctly
g) Log more set operations as some variables mysteriously acquired
values previously
h) Standardise infer_caller_details to be triggered from .record()
where at all possible to reduce overhead in non-enabled cases
i) Rename variable parameter names to match inference code
j) Add VariableHistory emit() function to match IncludeHistory
k) Fix handling of appendVar, prependVar and matching flag ops
l) Use ignored=True to stop logging further events where appropriate
(Bitbake rev: f00524a3729000cbcb3317fee933ac448fae5e2d)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-18 11:47:34 +00:00
|
|
|
flag = None
|
2009-05-18 17:50:14 +00:00
|
|
|
if 'flag' in groupd and groupd['flag'] != None:
|
bitbake: bitbake: data_smart.py and friends: Track variable history
This patch adds tracking of the history of variable assignments.
The changes are predominantly localized to data_smart.py and
parse/ast.py. cooker.py and data.py are altered to display the
recorded data, and turn tracking on for the bitbake -e case.
The data.py update_data() function warns DataSmart.finalize()
to report the caller one further back up the tree.
In general, d.setVar() does what it used to do. Optionally,
arguments describing an operation may be appended; if none
are present, the operation is implicitly ignored. If it's
not ignored, it will attempt to infer missing information
(name of variable, value assigned, file and line) by examining
the traceback. This slightly elaborate process eliminates a
category of problems in which the 'var' member of the keyword
arguments dict is set, and a positional argument corresponding
to 'var' is also set. It also makes calling much simpler for
the common cases.
The resulting output gives you a pretty good picture of what
values got set, and how they got set.
RP Modifications:
a) Split from IncludeHistory to separate VariableHistory
b) Add dedicated copy function instead of deepcopy
c) Use COW for variables dict
d) Remove 'value' loginfo value and just use 'details'
e) Desensitise code for calling order (set 'op' before/after
infer_caller_details was error prone)
f) Fix bug where ?= "" wasn't shown correctly
g) Log more set operations as some variables mysteriously acquired
values previously
h) Standardise infer_caller_details to be triggered from .record()
where at all possible to reduce overhead in non-enabled cases
i) Rename variable parameter names to match inference code
j) Add VariableHistory emit() function to match IncludeHistory
k) Fix handling of appendVar, prependVar and matching flag ops
l) Use ignored=True to stop logging further events where appropriate
(Bitbake rev: f00524a3729000cbcb3317fee933ac448fae5e2d)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-18 11:47:34 +00:00
|
|
|
flag = groupd['flag']
|
2010-02-25 16:42:28 +00:00
|
|
|
elif groupd["lazyques"]:
|
bitbake: bitbake: data_smart.py and friends: Track variable history
This patch adds tracking of the history of variable assignments.
The changes are predominantly localized to data_smart.py and
parse/ast.py. cooker.py and data.py are altered to display the
recorded data, and turn tracking on for the bitbake -e case.
The data.py update_data() function warns DataSmart.finalize()
to report the caller one further back up the tree.
In general, d.setVar() does what it used to do. Optionally,
arguments describing an operation may be appended; if none
are present, the operation is implicitly ignored. If it's
not ignored, it will attempt to infer missing information
(name of variable, value assigned, file and line) by examining
the traceback. This slightly elaborate process eliminates a
category of problems in which the 'var' member of the keyword
arguments dict is set, and a positional argument corresponding
to 'var' is also set. It also makes calling much simpler for
the common cases.
The resulting output gives you a pretty good picture of what
values got set, and how they got set.
RP Modifications:
a) Split from IncludeHistory to separate VariableHistory
b) Add dedicated copy function instead of deepcopy
c) Use COW for variables dict
d) Remove 'value' loginfo value and just use 'details'
e) Desensitise code for calling order (set 'op' before/after
infer_caller_details was error prone)
f) Fix bug where ?= "" wasn't shown correctly
g) Log more set operations as some variables mysteriously acquired
values previously
h) Standardise infer_caller_details to be triggered from .record()
where at all possible to reduce overhead in non-enabled cases
i) Rename variable parameter names to match inference code
j) Add VariableHistory emit() function to match IncludeHistory
k) Fix handling of appendVar, prependVar and matching flag ops
l) Use ignored=True to stop logging further events where appropriate
(Bitbake rev: f00524a3729000cbcb3317fee933ac448fae5e2d)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-18 11:47:34 +00:00
|
|
|
flag = "defaultval"
|
|
|
|
|
|
|
|
loginfo['op'] = op
|
|
|
|
loginfo['detail'] = groupd["value"]
|
|
|
|
|
|
|
|
if flag:
|
|
|
|
data.setVarFlag(key, flag, val, **loginfo)
|
2009-05-18 17:50:14 +00:00
|
|
|
else:
|
bitbake: bitbake: data_smart.py and friends: Track variable history
This patch adds tracking of the history of variable assignments.
The changes are predominantly localized to data_smart.py and
parse/ast.py. cooker.py and data.py are altered to display the
recorded data, and turn tracking on for the bitbake -e case.
The data.py update_data() function warns DataSmart.finalize()
to report the caller one further back up the tree.
In general, d.setVar() does what it used to do. Optionally,
arguments describing an operation may be appended; if none
are present, the operation is implicitly ignored. If it's
not ignored, it will attempt to infer missing information
(name of variable, value assigned, file and line) by examining
the traceback. This slightly elaborate process eliminates a
category of problems in which the 'var' member of the keyword
arguments dict is set, and a positional argument corresponding
to 'var' is also set. It also makes calling much simpler for
the common cases.
The resulting output gives you a pretty good picture of what
values got set, and how they got set.
RP Modifications:
a) Split from IncludeHistory to separate VariableHistory
b) Add dedicated copy function instead of deepcopy
c) Use COW for variables dict
d) Remove 'value' loginfo value and just use 'details'
e) Desensitise code for calling order (set 'op' before/after
infer_caller_details was error prone)
f) Fix bug where ?= "" wasn't shown correctly
g) Log more set operations as some variables mysteriously acquired
values previously
h) Standardise infer_caller_details to be triggered from .record()
where at all possible to reduce overhead in non-enabled cases
i) Rename variable parameter names to match inference code
j) Add VariableHistory emit() function to match IncludeHistory
k) Fix handling of appendVar, prependVar and matching flag ops
l) Use ignored=True to stop logging further events where appropriate
(Bitbake rev: f00524a3729000cbcb3317fee933ac448fae5e2d)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-18 11:47:34 +00:00
|
|
|
data.setVar(key, val, **loginfo)
|
2009-05-18 17:50:14 +00:00
|
|
|
|
2011-01-04 20:34:08 +00:00
|
|
|
class MethodNode(AstNode):
|
2014-02-22 16:52:29 +00:00
|
|
|
tr_tbl = string.maketrans('/.+-@%', '______')
|
|
|
|
|
2011-01-04 20:34:08 +00:00
|
|
|
def __init__(self, filename, lineno, func_name, body):
|
|
|
|
AstNode.__init__(self, filename, lineno)
|
2009-05-19 07:51:29 +00:00
|
|
|
self.func_name = func_name
|
|
|
|
self.body = body
|
|
|
|
|
|
|
|
def eval(self, data):
|
2012-08-22 12:54:47 +00:00
|
|
|
text = '\n'.join(self.body)
|
2009-05-19 07:51:29 +00:00
|
|
|
if self.func_name == "__anonymous":
|
2014-02-22 16:52:29 +00:00
|
|
|
funcname = ("__anon_%s_%s" % (self.lineno, self.filename.translate(MethodNode.tr_tbl)))
|
2013-05-23 09:47:10 +00:00
|
|
|
text = "def %s(d):\n" % (funcname) + text
|
|
|
|
bb.methodpool.insert_method(funcname, text, self.filename)
|
2011-11-25 14:57:53 +00:00
|
|
|
anonfuncs = data.getVar('__BBANONFUNCS') or []
|
2010-03-31 16:14:18 +00:00
|
|
|
anonfuncs.append(funcname)
|
2011-11-25 14:57:53 +00:00
|
|
|
data.setVar('__BBANONFUNCS', anonfuncs)
|
2012-08-22 19:01:55 +00:00
|
|
|
data.setVar(funcname, text)
|
2009-05-19 07:51:29 +00:00
|
|
|
else:
|
2011-11-25 14:57:53 +00:00
|
|
|
data.setVarFlag(self.func_name, "func", 1)
|
2012-08-22 12:54:47 +00:00
|
|
|
data.setVar(self.func_name, text)
|
2009-05-19 07:51:29 +00:00
|
|
|
|
2009-07-21 19:00:29 +00:00
|
|
|
class PythonMethodNode(AstNode):
|
2012-08-22 12:54:01 +00:00
|
|
|
def __init__(self, filename, lineno, function, modulename, body):
|
2011-01-04 20:34:08 +00:00
|
|
|
AstNode.__init__(self, filename, lineno)
|
|
|
|
self.function = function
|
2012-08-22 12:54:01 +00:00
|
|
|
self.modulename = modulename
|
2009-05-19 07:51:29 +00:00
|
|
|
self.body = body
|
|
|
|
|
|
|
|
def eval(self, data):
|
|
|
|
# Note we will add root to parsedmethods after having parse
|
|
|
|
# 'this' file. This means we will not parse methods from
|
|
|
|
# bb classes twice
|
2010-09-03 15:04:26 +00:00
|
|
|
text = '\n'.join(self.body)
|
2013-05-23 09:47:10 +00:00
|
|
|
bb.methodpool.insert_method(self.modulename, text, self.filename)
|
2011-11-25 14:57:53 +00:00
|
|
|
data.setVarFlag(self.function, "func", 1)
|
|
|
|
data.setVarFlag(self.function, "python", 1)
|
|
|
|
data.setVar(self.function, text)
|
2009-05-19 08:02:55 +00:00
|
|
|
|
2009-07-21 19:00:29 +00:00
|
|
|
class MethodFlagsNode(AstNode):
|
2011-01-04 20:34:08 +00:00
|
|
|
def __init__(self, filename, lineno, key, m):
|
|
|
|
AstNode.__init__(self, filename, lineno)
|
2009-05-19 08:02:55 +00:00
|
|
|
self.key = key
|
|
|
|
self.m = m
|
|
|
|
|
|
|
|
def eval(self, data):
|
2011-11-25 14:57:53 +00:00
|
|
|
if data.getVar(self.key):
|
2009-05-19 08:02:55 +00:00
|
|
|
# clean up old version of this piece of metadata, as its
|
|
|
|
# flags could cause problems
|
2011-11-25 14:57:53 +00:00
|
|
|
data.setVarFlag(self.key, 'python', None)
|
|
|
|
data.setVarFlag(self.key, 'fakeroot', None)
|
2009-05-19 08:02:55 +00:00
|
|
|
if self.m.group("py") is not None:
|
2011-11-25 14:57:53 +00:00
|
|
|
data.setVarFlag(self.key, "python", "1")
|
2009-05-19 08:02:55 +00:00
|
|
|
else:
|
2011-11-25 14:57:53 +00:00
|
|
|
data.delVarFlag(self.key, "python")
|
2009-05-19 08:02:55 +00:00
|
|
|
if self.m.group("fr") is not None:
|
2011-11-25 14:57:53 +00:00
|
|
|
data.setVarFlag(self.key, "fakeroot", "1")
|
2009-05-19 08:02:55 +00:00
|
|
|
else:
|
2011-11-25 14:57:53 +00:00
|
|
|
data.delVarFlag(self.key, "fakeroot")
|
2009-05-19 08:02:55 +00:00
|
|
|
|
2009-07-21 19:00:29 +00:00
|
|
|
class ExportFuncsNode(AstNode):
|
2012-12-11 00:01:56 +00:00
|
|
|
def __init__(self, filename, lineno, fns, classname):
|
2011-01-04 20:34:08 +00:00
|
|
|
AstNode.__init__(self, filename, lineno)
|
2011-01-04 20:07:27 +00:00
|
|
|
self.n = fns.split()
|
2012-12-11 00:01:56 +00:00
|
|
|
self.classname = classname
|
2009-05-19 08:10:26 +00:00
|
|
|
|
|
|
|
def eval(self, data):
|
2012-12-11 00:01:56 +00:00
|
|
|
|
|
|
|
for func in self.n:
|
|
|
|
calledfunc = self.classname + "_" + func
|
|
|
|
|
|
|
|
if data.getVar(func) and not data.getVarFlag(func, 'export_func'):
|
|
|
|
continue
|
|
|
|
|
|
|
|
if data.getVar(func):
|
|
|
|
data.setVarFlag(func, 'python', None)
|
|
|
|
data.setVarFlag(func, 'func', None)
|
|
|
|
|
|
|
|
for flag in [ "func", "python" ]:
|
|
|
|
if data.getVarFlag(calledfunc, flag):
|
|
|
|
data.setVarFlag(func, flag, data.getVarFlag(calledfunc, flag))
|
|
|
|
for flag in [ "dirs" ]:
|
|
|
|
if data.getVarFlag(func, flag):
|
|
|
|
data.setVarFlag(calledfunc, flag, data.getVarFlag(func, flag))
|
|
|
|
|
|
|
|
if data.getVarFlag(calledfunc, "python"):
|
|
|
|
data.setVar(func, " bb.build.exec_func('" + calledfunc + "', d)\n")
|
|
|
|
else:
|
|
|
|
data.setVar(func, " " + calledfunc + "\n")
|
|
|
|
data.setVarFlag(func, 'export_func', '1')
|
2009-05-19 08:52:18 +00:00
|
|
|
|
2009-07-21 19:00:29 +00:00
|
|
|
class AddTaskNode(AstNode):
|
2011-01-04 20:34:08 +00:00
|
|
|
def __init__(self, filename, lineno, func, before, after):
|
|
|
|
AstNode.__init__(self, filename, lineno)
|
2009-05-19 08:52:18 +00:00
|
|
|
self.func = func
|
|
|
|
self.before = before
|
|
|
|
self.after = after
|
|
|
|
|
|
|
|
def eval(self, data):
|
2013-12-18 10:45:02 +00:00
|
|
|
bb.build.addtask(self.func, self.before, self.after, data)
|
2009-05-19 08:52:18 +00:00
|
|
|
|
2013-12-18 10:44:30 +00:00
|
|
|
class DelTaskNode(AstNode):
|
|
|
|
def __init__(self, filename, lineno, func):
|
|
|
|
AstNode.__init__(self, filename, lineno)
|
|
|
|
self.func = func
|
|
|
|
|
|
|
|
def eval(self, data):
|
2013-12-18 10:45:02 +00:00
|
|
|
bb.build.deltask(self.func, data)
|
2013-12-18 10:44:30 +00:00
|
|
|
|
2009-07-21 19:00:29 +00:00
|
|
|
class BBHandlerNode(AstNode):
|
2011-01-04 20:34:08 +00:00
|
|
|
def __init__(self, filename, lineno, fns):
|
|
|
|
AstNode.__init__(self, filename, lineno)
|
2011-01-04 20:07:27 +00:00
|
|
|
self.hs = fns.split()
|
2009-05-19 08:52:18 +00:00
|
|
|
|
|
|
|
def eval(self, data):
|
2011-11-25 14:57:53 +00:00
|
|
|
bbhands = data.getVar('__BBHANDLERS') or []
|
2009-05-19 08:52:18 +00:00
|
|
|
for h in self.hs:
|
|
|
|
bbhands.append(h)
|
2011-11-25 14:57:53 +00:00
|
|
|
data.setVarFlag(h, "handler", 1)
|
|
|
|
data.setVar('__BBHANDLERS', bbhands)
|
2009-05-19 08:57:00 +00:00
|
|
|
|
2009-07-21 19:00:29 +00:00
|
|
|
class InheritNode(AstNode):
|
2011-01-04 20:34:08 +00:00
|
|
|
def __init__(self, filename, lineno, classes):
|
|
|
|
AstNode.__init__(self, filename, lineno)
|
2011-01-04 20:06:49 +00:00
|
|
|
self.classes = classes
|
2009-05-19 08:57:00 +00:00
|
|
|
|
|
|
|
def eval(self, data):
|
2012-02-23 17:38:08 +00:00
|
|
|
bb.parse.BBHandler.inherit(self.classes, self.filename, self.lineno, data)
|
2010-03-24 23:56:12 +00:00
|
|
|
|
2011-01-04 20:34:08 +00:00
|
|
|
def handleInclude(statements, filename, lineno, m, force):
|
|
|
|
statements.append(IncludeNode(filename, lineno, m.group(1), force))
|
2010-02-12 14:14:49 +00:00
|
|
|
|
2011-01-04 20:34:08 +00:00
|
|
|
def handleExport(statements, filename, lineno, m):
|
|
|
|
statements.append(ExportNode(filename, lineno, m.group(1)))
|
2010-02-12 14:14:49 +00:00
|
|
|
|
2011-01-04 20:34:08 +00:00
|
|
|
def handleData(statements, filename, lineno, groupd):
|
|
|
|
statements.append(DataNode(filename, lineno, groupd))
|
2010-02-12 14:14:49 +00:00
|
|
|
|
2011-01-04 20:34:08 +00:00
|
|
|
def handleMethod(statements, filename, lineno, func_name, body):
|
|
|
|
statements.append(MethodNode(filename, lineno, func_name, body))
|
2010-02-12 14:14:49 +00:00
|
|
|
|
2012-08-22 12:54:01 +00:00
|
|
|
def handlePythonMethod(statements, filename, lineno, funcname, modulename, body):
|
|
|
|
statements.append(PythonMethodNode(filename, lineno, funcname, modulename, body))
|
2010-02-12 14:14:49 +00:00
|
|
|
|
2011-01-04 20:34:08 +00:00
|
|
|
def handleMethodFlags(statements, filename, lineno, key, m):
|
|
|
|
statements.append(MethodFlagsNode(filename, lineno, key, m))
|
2010-02-12 14:14:49 +00:00
|
|
|
|
2012-12-11 00:01:56 +00:00
|
|
|
def handleExportFuncs(statements, filename, lineno, m, classname):
|
|
|
|
statements.append(ExportFuncsNode(filename, lineno, m.group(1), classname))
|
2010-02-12 14:14:49 +00:00
|
|
|
|
2011-01-04 20:34:08 +00:00
|
|
|
def handleAddTask(statements, filename, lineno, m):
|
2010-02-12 14:14:49 +00:00
|
|
|
func = m.group("func")
|
|
|
|
before = m.group("before")
|
|
|
|
after = m.group("after")
|
|
|
|
if func is None:
|
|
|
|
return
|
2009-05-19 08:52:18 +00:00
|
|
|
|
2011-01-04 20:34:08 +00:00
|
|
|
statements.append(AddTaskNode(filename, lineno, func, before, after))
|
2010-02-12 14:14:49 +00:00
|
|
|
|
2013-12-18 10:44:30 +00:00
|
|
|
def handleDelTask(statements, filename, lineno, m):
|
|
|
|
func = m.group("func")
|
|
|
|
if func is None:
|
|
|
|
return
|
|
|
|
|
|
|
|
statements.append(DelTaskNode(filename, lineno, func))
|
|
|
|
|
2011-01-04 20:34:08 +00:00
|
|
|
def handleBBHandlers(statements, filename, lineno, m):
|
|
|
|
statements.append(BBHandlerNode(filename, lineno, m.group(1)))
|
2010-02-12 14:14:49 +00:00
|
|
|
|
2011-01-04 20:34:08 +00:00
|
|
|
def handleInherit(statements, filename, lineno, m):
|
2011-01-04 20:06:49 +00:00
|
|
|
classes = m.group(1)
|
2012-03-03 09:45:58 +00:00
|
|
|
statements.append(InheritNode(filename, lineno, classes))
|
2010-02-12 14:14:49 +00:00
|
|
|
|
2010-08-31 13:49:43 +00:00
|
|
|
def finalize(fn, d, variant = None):
|
2010-03-31 03:06:07 +00:00
|
|
|
all_handlers = {}
|
2011-11-25 14:57:53 +00:00
|
|
|
for var in d.getVar('__BBHANDLERS') or []:
|
2009-05-18 17:56:36 +00:00
|
|
|
# try to add the handler
|
2013-05-31 14:19:14 +00:00
|
|
|
bb.event.register(var, d.getVar(var), (d.getVarFlag(var, "eventmask", True) or "").split())
|
2009-05-18 17:56:36 +00:00
|
|
|
|
2011-06-09 16:30:17 +00:00
|
|
|
bb.event.fire(bb.event.RecipePreFinalise(fn), d)
|
|
|
|
|
2011-06-17 16:37:20 +00:00
|
|
|
bb.data.expandKeys(d)
|
2011-06-09 16:30:17 +00:00
|
|
|
bb.data.update_data(d)
|
|
|
|
code = []
|
2011-11-25 14:57:53 +00:00
|
|
|
for funcname in d.getVar("__BBANONFUNCS") or []:
|
2011-06-09 16:30:17 +00:00
|
|
|
code.append("%s(d)" % funcname)
|
2012-08-21 16:25:07 +00:00
|
|
|
bb.utils.better_exec("\n".join(code), {"d": d})
|
2011-06-09 16:30:17 +00:00
|
|
|
bb.data.update_data(d)
|
|
|
|
|
2011-11-25 14:57:53 +00:00
|
|
|
tasklist = d.getVar('__BBTASKS') or []
|
2013-12-18 10:44:30 +00:00
|
|
|
deltasklist = d.getVar('__BBDELTASKS') or []
|
|
|
|
bb.build.add_tasks(tasklist, deltasklist, d)
|
2009-05-18 17:56:36 +00:00
|
|
|
|
2010-08-31 13:49:43 +00:00
|
|
|
bb.parse.siggen.finalise(fn, d, variant)
|
2010-08-03 13:30:20 +00:00
|
|
|
|
2012-02-28 03:22:40 +00:00
|
|
|
d.setVar('BBINCLUDED', bb.parse.get_file_depends(d))
|
|
|
|
|
2009-05-18 17:56:36 +00:00
|
|
|
bb.event.fire(bb.event.RecipeParsed(fn), d)
|
|
|
|
|
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+"
SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1"
Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb.
(Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-20 00:22:19 +00:00
|
|
|
def _create_variants(datastores, names, function):
|
|
|
|
def create_variant(name, orig_d, arg = None):
|
|
|
|
new_d = bb.data.createCopy(orig_d)
|
|
|
|
function(arg or name, new_d)
|
|
|
|
datastores[name] = new_d
|
|
|
|
|
|
|
|
for variant, variant_d in datastores.items():
|
|
|
|
for name in names:
|
|
|
|
if not variant:
|
|
|
|
# Based on main recipe
|
|
|
|
create_variant(name, variant_d)
|
|
|
|
else:
|
|
|
|
create_variant("%s-%s" % (variant, name), variant_d, name)
|
|
|
|
|
|
|
|
def _expand_versions(versions):
|
|
|
|
def expand_one(version, start, end):
|
|
|
|
for i in xrange(start, end + 1):
|
|
|
|
ver = _bbversions_re.sub(str(i), version, 1)
|
|
|
|
yield ver
|
|
|
|
|
|
|
|
versions = iter(versions)
|
|
|
|
while True:
|
|
|
|
try:
|
2010-06-20 19:08:07 +00:00
|
|
|
version = next(versions)
|
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+"
SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1"
Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb.
(Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-20 00:22:19 +00:00
|
|
|
except StopIteration:
|
|
|
|
break
|
|
|
|
|
|
|
|
range_ver = _bbversions_re.search(version)
|
|
|
|
if not range_ver:
|
|
|
|
yield version
|
|
|
|
else:
|
|
|
|
newversions = expand_one(version, int(range_ver.group("from")),
|
|
|
|
int(range_ver.group("to")))
|
2010-06-20 19:08:07 +00:00
|
|
|
versions = itertools.chain(newversions, versions)
|
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+"
SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1"
Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb.
(Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-20 00:22:19 +00:00
|
|
|
|
|
|
|
def multi_finalize(fn, d):
|
2010-07-16 14:10:22 +00:00
|
|
|
appends = (d.getVar("__BBAPPEND", True) or "").split()
|
|
|
|
for append in appends:
|
2010-06-10 17:35:31 +00:00
|
|
|
logger.debug(2, "Appending .bbappend file %s to %s", append, fn)
|
2010-07-16 14:10:22 +00:00
|
|
|
bb.parse.BBHandler.handle(append, d, True)
|
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+"
SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1"
Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb.
(Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-20 00:22:19 +00:00
|
|
|
|
2011-04-10 17:50:16 +00:00
|
|
|
onlyfinalise = d.getVar("__ONLYFINALISE", False)
|
|
|
|
|
2010-07-16 14:10:22 +00:00
|
|
|
safe_d = d
|
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+"
SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1"
Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb.
(Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-20 00:22:19 +00:00
|
|
|
d = bb.data.createCopy(safe_d)
|
|
|
|
try:
|
2011-06-01 11:22:17 +00:00
|
|
|
finalize(fn, d)
|
2011-06-01 14:37:07 +00:00
|
|
|
except bb.parse.SkipPackage as e:
|
2011-11-25 14:57:53 +00:00
|
|
|
d.setVar("__SKIPPED", e.args[0])
|
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+"
SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1"
Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb.
(Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-20 00:22:19 +00:00
|
|
|
datastores = {"": safe_d}
|
|
|
|
|
|
|
|
versions = (d.getVar("BBVERSIONS", True) or "").split()
|
|
|
|
if versions:
|
|
|
|
pv = orig_pv = d.getVar("PV", True)
|
|
|
|
baseversions = {}
|
|
|
|
|
|
|
|
def verfunc(ver, d, pv_d = None):
|
|
|
|
if pv_d is None:
|
|
|
|
pv_d = d
|
|
|
|
|
|
|
|
overrides = d.getVar("OVERRIDES", True).split(":")
|
|
|
|
pv_d.setVar("PV", ver)
|
|
|
|
overrides.append(ver)
|
|
|
|
bpv = baseversions.get(ver) or orig_pv
|
|
|
|
pv_d.setVar("BPV", bpv)
|
|
|
|
overrides.append(bpv)
|
|
|
|
d.setVar("OVERRIDES", ":".join(overrides))
|
|
|
|
|
|
|
|
versions = list(_expand_versions(versions))
|
|
|
|
for pos, version in enumerate(list(versions)):
|
|
|
|
try:
|
|
|
|
pv, bpv = version.split(":", 2)
|
|
|
|
except ValueError:
|
|
|
|
pass
|
|
|
|
else:
|
|
|
|
versions[pos] = pv
|
|
|
|
baseversions[pv] = bpv
|
|
|
|
|
|
|
|
if pv in versions and not baseversions.get(pv):
|
|
|
|
versions.remove(pv)
|
|
|
|
else:
|
|
|
|
pv = versions.pop()
|
|
|
|
|
|
|
|
# This is necessary because our existing main datastore
|
|
|
|
# has already been finalized with the old PV, we need one
|
|
|
|
# that's been finalized with the new PV.
|
|
|
|
d = bb.data.createCopy(safe_d)
|
|
|
|
verfunc(pv, d, safe_d)
|
|
|
|
try:
|
2010-04-08 23:01:14 +00:00
|
|
|
finalize(fn, d)
|
2011-06-01 14:37:07 +00:00
|
|
|
except bb.parse.SkipPackage as e:
|
2011-11-25 14:57:53 +00:00
|
|
|
d.setVar("__SKIPPED", e.args[0])
|
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+"
SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1"
Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb.
(Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-20 00:22:19 +00:00
|
|
|
|
|
|
|
_create_variants(datastores, versions, verfunc)
|
|
|
|
|
|
|
|
extended = d.getVar("BBCLASSEXTEND", True) or ""
|
|
|
|
if extended:
|
2011-07-22 14:37:44 +00:00
|
|
|
# the following is to support bbextends with arguments, for e.g. multilib
|
|
|
|
# an example is as follows:
|
2011-06-07 09:16:52 +00:00
|
|
|
# BBCLASSEXTEND = "multilib:lib32"
|
|
|
|
# it will create foo-lib32, inheriting multilib.bbclass and set
|
2011-07-22 14:37:44 +00:00
|
|
|
# BBEXTENDCURR to "multilib" and BBEXTENDVARIANT to "lib32"
|
2011-06-07 09:16:52 +00:00
|
|
|
extendedmap = {}
|
2011-07-22 14:37:44 +00:00
|
|
|
variantmap = {}
|
2011-06-07 09:16:52 +00:00
|
|
|
|
|
|
|
for ext in extended.split():
|
2011-07-22 14:37:44 +00:00
|
|
|
eext = ext.split(':', 2)
|
2011-06-07 09:16:52 +00:00
|
|
|
if len(eext) > 1:
|
2011-07-22 14:37:44 +00:00
|
|
|
extendedmap[ext] = eext[0]
|
|
|
|
variantmap[ext] = eext[1]
|
2011-06-07 09:16:52 +00:00
|
|
|
else:
|
|
|
|
extendedmap[ext] = ext
|
|
|
|
|
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+"
SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1"
Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb.
(Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-20 00:22:19 +00:00
|
|
|
pn = d.getVar("PN", True)
|
|
|
|
def extendfunc(name, d):
|
2011-06-07 09:16:52 +00:00
|
|
|
if name != extendedmap[name]:
|
|
|
|
d.setVar("BBEXTENDCURR", extendedmap[name])
|
2011-07-22 14:37:44 +00:00
|
|
|
d.setVar("BBEXTENDVARIANT", variantmap[name])
|
2011-06-07 09:16:52 +00:00
|
|
|
else:
|
|
|
|
d.setVar("PN", "%s-%s" % (pn, name))
|
2012-03-03 09:45:58 +00:00
|
|
|
bb.parse.BBHandler.inherit(extendedmap[name], fn, 0, d)
|
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+"
SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1"
Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb.
(Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-20 00:22:19 +00:00
|
|
|
|
|
|
|
safe_d.setVar("BBCLASSEXTEND", extended)
|
2011-06-07 09:16:52 +00:00
|
|
|
_create_variants(datastores, extendedmap.keys(), extendfunc)
|
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+"
SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1"
Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb.
(Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-20 00:22:19 +00:00
|
|
|
|
2010-06-20 19:08:07 +00:00
|
|
|
for variant, variant_d in datastores.iteritems():
|
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+"
SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1"
Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb.
(Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-20 00:22:19 +00:00
|
|
|
if variant:
|
|
|
|
try:
|
2011-04-10 17:50:16 +00:00
|
|
|
if not onlyfinalise or variant in onlyfinalise:
|
|
|
|
finalize(fn, variant_d, variant)
|
2011-06-01 14:37:07 +00:00
|
|
|
except bb.parse.SkipPackage as e:
|
2011-11-25 14:57:53 +00:00
|
|
|
variant_d.setVar("__SKIPPED", e.args[0])
|
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+"
SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1"
Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb.
(Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-20 00:22:19 +00:00
|
|
|
|
|
|
|
if len(datastores) > 1:
|
2010-06-20 19:08:07 +00:00
|
|
|
variants = filter(None, datastores.iterkeys())
|
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+"
SRC_URI_append_1.0.7+ = "file://some_extra_patch.patch;patch=1"
Or you can create a recipe per range, and name the recipe file as such: nano_1.0.7+.bb.
(Bitbake rev: 4ee9a56e16f1eb3c1649eaa3127b09ab0e93d1ec)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-03-20 00:22:19 +00:00
|
|
|
safe_d.setVar("__VARIANTS", " ".join(variants))
|
|
|
|
|
|
|
|
datastores[""] = d
|
|
|
|
return datastores
|