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 :
2015-05-22 10:30:57 +00:00
return data . getVar ( key , False , noweakdefault = True , parsing = 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 " ] :
2014-12-01 20:50:14 +00:00
flag = " _defaultval "
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 [ ' op ' ] = op
loginfo [ ' detail ' ] = groupd [ " value " ]
if flag :
data . setVarFlag ( key , flag , val , * * loginfo )
2009-05-18 17:50:14 +00:00
else :
2015-05-22 10:30:57 +00:00
data . setVar ( key , val , parsing = True , * * loginfo )
2009-05-18 17:50:14 +00:00
2011-01-04 20:34:08 +00:00
class MethodNode ( AstNode ) :
2015-01-29 08:52:04 +00:00
tr_tbl = string . maketrans ( ' /.+-@ % & ' , ' _______ ' )
2014-02-22 16:52:29 +00:00
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 )
bitbake: ast/event/utils: Improve tracebacks to include file and line numbers more correctly
Currently bitbake tracebacks can have places where the line numbers are
inaccurate and filenames may be missing. These changes start to try and
correct this.
The only way I could find to correct line numbers was to compile as a
python ast, tweak the line numbers then compile to bytecode. I'm open
to better ways of doing this if anyone knows of any.
This does mean passing a few more parameters into functions, and putting
more data into the data store about functions (i.e. their filenames
and line numbers) but the improvement in debugging is more than worthwhile).
Before:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "run_buildstats(e)", line 43, in run_buildstats(e=<bb.build.TaskStarted object at 0x7f7b7c57a590>)
NameError: global name 'notexist' is not defined
ERROR: Build of do_patch failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "run_buildstats(e)", line 43, in run_buildstats
NameError: global name 'notexist' is not defined
----------------
After:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats(e=<bb.build.TaskStarted object at 0x7efe89284e10>):
if isinstance(e, bb.build.TaskStarted):
> trigger = notexist
pn = d.getVar("PN", True)
NameError: global name 'notexist' is not defined
ERROR: Build of do_package failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats
trigger = notexist
NameError: global name 'notexist' is not defined
----------------
(Bitbake rev: 1ff860960919ff6f8097138bc68de85bcb5f88b0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-15 17:41:12 +00:00
funcname = self . func_name
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
bitbake: ast/event/utils: Improve tracebacks to include file and line numbers more correctly
Currently bitbake tracebacks can have places where the line numbers are
inaccurate and filenames may be missing. These changes start to try and
correct this.
The only way I could find to correct line numbers was to compile as a
python ast, tweak the line numbers then compile to bytecode. I'm open
to better ways of doing this if anyone knows of any.
This does mean passing a few more parameters into functions, and putting
more data into the data store about functions (i.e. their filenames
and line numbers) but the improvement in debugging is more than worthwhile).
Before:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "run_buildstats(e)", line 43, in run_buildstats(e=<bb.build.TaskStarted object at 0x7f7b7c57a590>)
NameError: global name 'notexist' is not defined
ERROR: Build of do_patch failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "run_buildstats(e)", line 43, in run_buildstats
NameError: global name 'notexist' is not defined
----------------
After:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats(e=<bb.build.TaskStarted object at 0x7efe89284e10>):
if isinstance(e, bb.build.TaskStarted):
> trigger = notexist
pn = d.getVar("PN", True)
NameError: global name 'notexist' is not defined
ERROR: Build of do_package failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats
trigger = notexist
NameError: global name 'notexist' is not defined
----------------
(Bitbake rev: 1ff860960919ff6f8097138bc68de85bcb5f88b0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-15 17:41:12 +00:00
bb . methodpool . insert_method ( funcname , text , self . filename , self . lineno - len ( self . body ) )
2015-06-18 14:14:19 +00:00
anonfuncs = data . getVar ( ' __BBANONFUNCS ' , False ) or [ ]
2010-03-31 16:14:18 +00:00
anonfuncs . append ( funcname )
2011-11-25 14:57:53 +00:00
data . setVar ( ' __BBANONFUNCS ' , anonfuncs )
2009-05-19 07:51:29 +00:00
else :
2011-11-25 14:57:53 +00:00
data . setVarFlag ( self . func_name , " func " , 1 )
bitbake: ast/event/utils: Improve tracebacks to include file and line numbers more correctly
Currently bitbake tracebacks can have places where the line numbers are
inaccurate and filenames may be missing. These changes start to try and
correct this.
The only way I could find to correct line numbers was to compile as a
python ast, tweak the line numbers then compile to bytecode. I'm open
to better ways of doing this if anyone knows of any.
This does mean passing a few more parameters into functions, and putting
more data into the data store about functions (i.e. their filenames
and line numbers) but the improvement in debugging is more than worthwhile).
Before:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "run_buildstats(e)", line 43, in run_buildstats(e=<bb.build.TaskStarted object at 0x7f7b7c57a590>)
NameError: global name 'notexist' is not defined
ERROR: Build of do_patch failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "run_buildstats(e)", line 43, in run_buildstats
NameError: global name 'notexist' is not defined
----------------
After:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats(e=<bb.build.TaskStarted object at 0x7efe89284e10>):
if isinstance(e, bb.build.TaskStarted):
> trigger = notexist
pn = d.getVar("PN", True)
NameError: global name 'notexist' is not defined
ERROR: Build of do_package failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats
trigger = notexist
NameError: global name 'notexist' is not defined
----------------
(Bitbake rev: 1ff860960919ff6f8097138bc68de85bcb5f88b0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-15 17:41:12 +00:00
data . setVar ( funcname , text , parsing = True )
data . setVarFlag ( funcname , ' filename ' , self . filename )
data . setVarFlag ( funcname , ' lineno ' , str ( self . lineno - len ( self . body ) ) )
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 )
bitbake: ast/event/utils: Improve tracebacks to include file and line numbers more correctly
Currently bitbake tracebacks can have places where the line numbers are
inaccurate and filenames may be missing. These changes start to try and
correct this.
The only way I could find to correct line numbers was to compile as a
python ast, tweak the line numbers then compile to bytecode. I'm open
to better ways of doing this if anyone knows of any.
This does mean passing a few more parameters into functions, and putting
more data into the data store about functions (i.e. their filenames
and line numbers) but the improvement in debugging is more than worthwhile).
Before:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "run_buildstats(e)", line 43, in run_buildstats(e=<bb.build.TaskStarted object at 0x7f7b7c57a590>)
NameError: global name 'notexist' is not defined
ERROR: Build of do_patch failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "run_buildstats(e)", line 43, in run_buildstats
NameError: global name 'notexist' is not defined
----------------
After:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats(e=<bb.build.TaskStarted object at 0x7efe89284e10>):
if isinstance(e, bb.build.TaskStarted):
> trigger = notexist
pn = d.getVar("PN", True)
NameError: global name 'notexist' is not defined
ERROR: Build of do_package failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats
trigger = notexist
NameError: global name 'notexist' is not defined
----------------
(Bitbake rev: 1ff860960919ff6f8097138bc68de85bcb5f88b0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-15 17:41:12 +00:00
bb . methodpool . insert_method ( self . modulename , text , self . filename , self . lineno - len ( self . body ) - 1 )
2011-11-25 14:57:53 +00:00
data . setVarFlag ( self . function , " func " , 1 )
data . setVarFlag ( self . function , " python " , 1 )
2015-05-22 10:30:57 +00:00
data . setVar ( self . function , text , parsing = True )
bitbake: ast/event/utils: Improve tracebacks to include file and line numbers more correctly
Currently bitbake tracebacks can have places where the line numbers are
inaccurate and filenames may be missing. These changes start to try and
correct this.
The only way I could find to correct line numbers was to compile as a
python ast, tweak the line numbers then compile to bytecode. I'm open
to better ways of doing this if anyone knows of any.
This does mean passing a few more parameters into functions, and putting
more data into the data store about functions (i.e. their filenames
and line numbers) but the improvement in debugging is more than worthwhile).
Before:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "run_buildstats(e)", line 43, in run_buildstats(e=<bb.build.TaskStarted object at 0x7f7b7c57a590>)
NameError: global name 'notexist' is not defined
ERROR: Build of do_patch failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "run_buildstats(e)", line 43, in run_buildstats
NameError: global name 'notexist' is not defined
----------------
After:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats(e=<bb.build.TaskStarted object at 0x7efe89284e10>):
if isinstance(e, bb.build.TaskStarted):
> trigger = notexist
pn = d.getVar("PN", True)
NameError: global name 'notexist' is not defined
ERROR: Build of do_package failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats
trigger = notexist
NameError: global name 'notexist' is not defined
----------------
(Bitbake rev: 1ff860960919ff6f8097138bc68de85bcb5f88b0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-15 17:41:12 +00:00
data . setVarFlag ( self . function , ' filename ' , self . filename )
data . setVarFlag ( self . function , ' lineno ' , str ( self . lineno - len ( self . body ) - 1 ) )
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 ) :
2015-06-18 14:14:19 +00:00
if data . getVar ( self . key , False ) :
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
2015-06-18 14:14:19 +00:00
if data . getVar ( func , False ) and not data . getVarFlag ( func , ' export_func ' ) :
2012-12-11 00:01:56 +00:00
continue
2015-06-18 14:14:19 +00:00
if data . getVar ( func , False ) :
2012-12-11 00:01:56 +00:00
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 " ) :
2015-05-22 10:30:57 +00:00
data . setVar ( func , " bb.build.exec_func( ' " + calledfunc + " ' , d) \n " , parsing = True )
2012-12-11 00:01:56 +00:00
else :
2015-01-08 10:35:16 +00:00
if " - " in self . classname :
bb . fatal ( " The classname %s contains a dash character and is calling an sh function %s using EXPORT_FUNCTIONS. Since a dash is illegal in sh function names, this cannot work, please rename the class or don ' t use EXPORT_FUNCTIONS. " % ( self . classname , calledfunc ) )
2015-05-22 10:30:57 +00:00
data . setVar ( func , " " + calledfunc + " \n " , parsing = True )
2012-12-11 00:01:56 +00:00
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 ) :
2015-06-18 14:14:19 +00:00
bbhands = data . getVar ( ' __BBHANDLERS ' , False ) 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 = { }
2015-06-18 14:14:19 +00:00
for var in d . getVar ( ' __BBHANDLERS ' , False ) or [ ] :
2009-05-18 17:56:36 +00:00
# try to add the handler
bitbake: ast/event/utils: Improve tracebacks to include file and line numbers more correctly
Currently bitbake tracebacks can have places where the line numbers are
inaccurate and filenames may be missing. These changes start to try and
correct this.
The only way I could find to correct line numbers was to compile as a
python ast, tweak the line numbers then compile to bytecode. I'm open
to better ways of doing this if anyone knows of any.
This does mean passing a few more parameters into functions, and putting
more data into the data store about functions (i.e. their filenames
and line numbers) but the improvement in debugging is more than worthwhile).
Before:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "run_buildstats(e)", line 43, in run_buildstats(e=<bb.build.TaskStarted object at 0x7f7b7c57a590>)
NameError: global name 'notexist' is not defined
ERROR: Build of do_patch failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "run_buildstats(e)", line 43, in run_buildstats
NameError: global name 'notexist' is not defined
----------------
After:
----------------
ERROR: Execution of event handler 'run_buildstats' failed
Traceback (most recent call last):
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats(e=<bb.build.TaskStarted object at 0x7efe89284e10>):
if isinstance(e, bb.build.TaskStarted):
> trigger = notexist
pn = d.getVar("PN", True)
NameError: global name 'notexist' is not defined
ERROR: Build of do_package failed
ERROR: Traceback (most recent call last):
File "/media/build1/poky/bitbake/lib/bb/build.py", line 560, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/media/build1/poky/bitbake/lib/bb/build.py", line 497, in _exec_task
event.fire(TaskStarted(task, logfn, flags, localdata), localdata)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 170, in fire
fire_class_handlers(event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 109, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/media/build1/poky/bitbake/lib/bb/event.py", line 81, in execute_handler
ret = handler(event)
File "/media/build1/poky/meta/classes/buildstats.bbclass", line 143, in run_buildstats
trigger = notexist
NameError: global name 'notexist' is not defined
----------------
(Bitbake rev: 1ff860960919ff6f8097138bc68de85bcb5f88b0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-12-15 17:41:12 +00:00
handlerfn = d . getVarFlag ( var , " filename " , False )
handlerln = int ( d . getVarFlag ( var , " lineno " , False ) )
bb . event . register ( var , d . getVar ( var , False ) , ( d . getVarFlag ( var , " eventmask " , True ) or " " ) . split ( ) , handlerfn , handlerln )
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 = [ ]
2015-06-18 14:14:19 +00:00
for funcname in d . getVar ( " __BBANONFUNCS " , False ) 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 )
2015-06-18 14:14:19 +00:00
tasklist = d . getVar ( ' __BBTASKS ' , False ) or [ ]
2015-08-03 19:20:43 +00:00
bb . build . add_tasks ( tasklist , 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 )
2014-04-13 10:48:53 +00:00
def _create_variants ( datastores , names , function , onlyfinalise ) :
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_variant ( name , orig_d , arg = None ) :
2014-04-13 10:48:53 +00:00
if onlyfinalise and name not in onlyfinalise :
return
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
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 :
2014-05-09 12:31:25 +00:00
logger . debug ( 1 , " 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 )
2014-05-30 14:55:37 +00:00
except bb . parse . SkipRecipe 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 )
2014-05-30 14:55:37 +00:00
except bb . parse . SkipRecipe 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
2014-04-13 10:48:53 +00:00
_create_variants ( datastores , versions , verfunc , onlyfinalise )
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
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 )
2014-04-13 10:48:53 +00:00
_create_variants ( datastores , extendedmap . keys ( ) , extendfunc , onlyfinalise )
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 )
2014-05-30 14:55:37 +00:00
except bb . parse . SkipRecipe 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