Looking at this function I had no idea what oldfn was, I doubt anyone
else would either without looking up what the caller does. "parentfn"
would seem a more appropriate name so rename it.
(Bitbake rev: fc70ed596703a1aa954223b169d4ad51193a6ec1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Memory resident bitbake has one current flaw, changes in the base configuration
are not noticed by bitbake. The parsing cache is also refreshed on each invocation
of bitbake (although the mtime cache is not cleared so its pointless).
This change adds in pyinotify support and adds two different watchers, one
for the base configuration and one for the parsed recipes.
Changes in the latter will trigger a reparse (and an update of the mtime cache).
The former will trigger a complete reload of the configuration.
Note that this code will also correctly handle creation of new configuration files
since the __depends and __base_depends variables already track these for cache
correctness purposes.
We could be a little more clever about parsing cache invalidation, right now we just
invalidate the whole thing and recheck. For now, its better than what we have and doesn't
seem to perform that badly though.
For education and QA purposes I can document a workflow that illustrates this:
$ source oe-init-build-env-memres
$ time bitbake bash
[base configuration is loaded, recipes are parsed, bash builds]
$ time bitbake bash
[command returns quickly since all caches are valid]
$ touch ../meta/classes/gettext.bbclass
$ time bitbake bash
[reparse is triggered, time is longer than above]
$ echo 'FOO = "1"' >> conf/local.conf
$ time bitbake bash
[reparse is triggered, but with a base configuration reload too]
As far as changes go, I like this one a lot, it makes memory resident bitbake
truly usable and may be the tweak we need to make it the default.
The new pyinotify dependency is covered in the previous commit.
(Bitbake rev: 0557d03c170fba8d7efe82be1b9641d0eb229213)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A dash character is illegal in function names in sh (but not bash). Since
our shell tasks run under sh and the shell parser is sh based, EXPORT_FUNCTIONS
won't work with class names containing a dash.
We can't change sh, we can ensure the user is warned about the problem
straight away though.
[YOCTO #7006]
(Bitbake rev: 86704281b79e524dccccc88cbf996b299b33bae2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The defaultval field is intended to be internal and the only use of that field
outside of data.py is to skip over it when iterating over a value's flags.
For clarity and convenience, rename the field to _defaultval so that it is
considered internal and not exposed through the data API.
(Bitbake rev: 2800958dadaa5c055ba21d52c98d842d360f0785)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the depths of time we were rather confused about naming. bb files
are recipes, the event to skip parsing them should be SkipRecipe,
not SkipPackage. This changes bitbake to use the better name but
leaves the other around for now. We can therefore start removing
references to it from the metadata.
(Bitbake rev: 98d9e6e0f514a7cb7da1d99bf4bd5602b89426d6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The file inheritance logging has been here since the dawn of time. It
duplicates output many times over and logs to debug level 2. When running
with the debug option, its understandable the user may want to see the
paths of files included in the build.
These changes remove pointless/duplicate output and print the
include paths clearly at debug level one in a form which
users should be able to more easily parse.
(Bitbake rev: 633a56987df639295fe9128418da5634050063e5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It was reported that bitbake -D made no mention of which append files it
was using. bitbake -DD does but it makes sense to increase the log level
of this piece of debug information.
[YOCTO #6262]
(Bitbake rev: 5824bf9c6feea05567d155911f4ab2e371911d34)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The optimisation where only the data we're interested in was finalised
was good but it turns out we can do better. In the case where a
class-extension is to be targeted, we can skip the other targets.
This change does that and speeds up parsing at the bitbake-worker
execution time. Specifically, you can see an improvement in the speed
of bitbake X -n.
(Bitbake rev: b56918c7ef7913e84356c69ee9b269844a446728)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When an evaluation was made for a configuration file the path to the
file was saved as a relative one. The change in this commit will save the
location as an absolute path. This way the user will have full information
regarding the location of the file where a variable was changed and the
line withing the file.
[YOCTO #5562]
(Bitbake rev: df9e22901555b06fef308f7136547f2c47ccec35)
Signed-off-by: Marius Avram <marius.avram@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using wildcard .bbappend files with anonymous methods in them,
bitbake/python fails to parse the generated code since the '%' is encoded
in the generated method name.
Fix this by including '%' in the convert-to-underscore list during
method name mangling.
While we're at it, move the method name mangling translation table
to a class variable, as suggested by Chris Larson.
[YOCTO #5864]
(Bitbake rev: 537f1f9bbe110acc9848ef95f43468c07d87af79)
Signed-off-by: Jacob Kroon <jacob.kroon@mikrodidakt.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It doesn't really make sense to set PN from .conf files, for example.
More concretely, this avoids the config hash changing unnecessarily
within Hob due to PN effectively changing (since bblayers.conf is
parsed first and then .hob.conf).
(Bitbake rev: 22e03ef7ac9bb6b7245250347ae9c10c19f1d74e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently its near impossible to control task addition/deletion from
metadata context. This adds stong add/deltask API to bb.build
which is traditionally where it resided. The rather broken
remove_tasks function was removed, it didn't appear to do anything
useful or have any users.
This allows us to clean up hacks currently in use in metadata and use
standard API for it instead.
(Bitbake rev: bf7138dd38fc1f8efca80891198e3422fef64093)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Back in the depths of time we did support task removal. In the pre
AST days it was nearly impossible to continue supporting it, it wasn't
used so it was dropped. With the modern codebase we can easily now support
deltask and it would be very useful within the metadata since it can
massively simplify dependency trees.
As an example, a core-image-sato had 47703 inter task dependencies before
this patch and a patch to native.bbclass, afterwards with the noexec tasks
deleted, we had 29883. Such a significant simplification is worthwhile
and justifies adding a deltask operation to the system.
(Bitbake rev: acecbde6fb70ff3c96deab3cdf819d8442e87ed4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently bitbake only adds files to its dependency list if they exist.
If you add 'include foo.inc' to your recipe and the file doesn't exist,
then later you add the file, the cache will not be invalidated.
This leads to another bug which is that if files don't exist and then
you add them and they should be found first due to BBPATH, again the
cache won't invalidate.
This patch adds in tracking of files we check for the existence of so
that if they are added later, the cache correctly invalidates. This
necessitated a new version of bb.utils.which which returns a list of
files tested for.
The patch also adds in checks for duplicate file includes and for now
prints a warning about this. That will likely become a fatal error at
some point since its never usually desired to include a file twice.
The same issue is also fixed for class inheritance. Now when a class
is added which would be found in the usual search path, it will cause
the cache to be invalidated.
Unfortunately this is old code in bitbake and the patch isn't the
neatest since we have to work within that framework.
[YOCTO #5611]
[YOCTO #4425]
(Bitbake rev: 78d285871e4b8c54ccc4602d571e85f922e37ccd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* resolve_file was behaving different when relative and absolute
paths were passed to it
* include relative-path/non-existent-file.inc
works correctly resolve_file throws IOError, BBHandler.py:handle()
doesn't catch it, ConfHandler.py:include() catches IOError and shows:
DEBUG: CONF file 'relative-path/non-existent-file.inc' not found
* include /absolute-path/non-existent-file.inc
was failing, because resolve_file just returns fn,
BBHandler.py:handle() calls bb.parse.mark_dependency(d, abs_fn)
which throws:
OSError: [Errno 2] No such file or directory: '/absolute-path/non-existent-file.inc'
and parsing fails.
Ad isfile() test for absolute fn and throw IOError to make
resolve_file behavior consistent for both paths.
* I know we had some issues with -b relative-path-to-recipe.bb and
absolute path, so consider this patch only as RFC and documentation of
this problem
* Catch OSError too in ConfHandler.py:include() e.g. in case the file exists, but user
cannot read it or something like that.
(Bitbake rev: b0bbd89a4f0b98fa1ab28b8e0526cd9ddb76fa57)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #4772]
When path:file change to python function, it maybe include '@' character.
So, add the special character to change to '_' for avoid error.
(Bitbake rev: 684bc6dcb11ecb1fd7a4d25c08909ad9879e8342)
Signed-off-by: Li Wang <li.wang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a flag to event handlers which lists the events a given handler wishes to
process. By default event handlers recieve all events but this means
we can stop running code in many cases if we know it doesn't want the event.
This is part of the fix for YOCTO #3812, but implements filtering only
for class event handlers; the other part (events filter for UIs) will be
the subject of a different patch.
(Bitbake rev: 074003a4e7530a72863b9c685fc5c31b0f08c039)
Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having a global method scope confuses users and with the introduction
of parallel parsing, its not even possible to correctly detect conflicting
functions. Rather than try and fix that, its simpler to retire the global
method scope and restrict functions to those locations they're defined
within. This is more what users actually expect too.
If we remove the global function scope, the need for methodpool is reduced
to the point we may as well retire it. There is some small loss of caching
of parsed functions but timing measurements so the impact to be neglibile
in the overall parsing time.
(Bitbake rev: 4d50690489ee8dc329a9b0c7bc4ceb29b71e95e9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Python 3 is stricter about how files are accessed. Specficially:
* Use open(), not file()
* Use binary mode for binary files (when checksumming)
* Use with statements to ensure files get closed
* Add missing file close statements
(Bitbake rev: 9f08b901375ba640f47596f1bcf43f98a931550f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The __config_regexp__ in ConfHandler is quite long, and using re.X to
break the expression onto several lines make it a bit easier to read.
(Bitbake rev: 54dce9e14ab0657d76f0d0ae22eef7fab8e8950d)
Signed-off-by: Olof Johansson <olof.johansson@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you have:
FOO = "a"
FOO += "b"
FOO+= "c"
The expected result is "a b c" however we were seeing "a b" with the FOO+
variable being assigned the value "c". This isn't the expected result.
We need to make the name part of the variale non-greedy so that any + character
becomes part of the operator. This patch does that. I compared the configuration
in OE-Core before and after the change and only the test case changed.
[YOCTO #3834]
(Bitbake rev: 2cd8d7fd12a646e6516e2c985e6a54121d19eb59)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- enable the '~' character in bitbake variables
(Bitbake rev: 7c15ff1d50d7b601414f1d55c90e3c59981a0876)
Signed-off-by: Constantin Musca <constantinx.musca@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was meant to be squashed into the previous commit for multiline comment
handling. It fixes the case the commented multiline is followed by an empty
line which was resulting in a traceback instead of a sane error message.
(Bitbake rev: 7e7d692e244fe8dca533f842ca143b9c821e317c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Faced with an expression like:
# Some comment \
FOO = "bar"
what should bitbake do? Technically, the \ character means its multiline and
currently the code treats this as a continuation of the comment. This can
surprise some people and is not intuitive.
This patch makes bitbake simply error and asks the user to be clearer
about what they mean.
(Bitbake rev: 589d31ce41e019ee6a7cb6527d67bc76c0b6382a)
(Bitbake rev: 79c00fabe08b4c210a3bd81cfaffbc47ffdc2e2b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
This code adds inclusion history to bitbake -e output, showing
which files were included, in what order. This doesn't completely
resolve timing questions, because it doesn't show you which lines
of a file were processed before or after a given include, but it
does let you figure out what the path was by which a particular
file ended up in your build at all.
How it works: data_smart acquires a .history member, which is an
IncludeHistory; this represents the inclusion of a file and all its
inclusions, recursively. It provides methods for including files,
for finishing inclusion (done as an __exit__), and for
dumping the whole tree.
The parser is modified to run includes inside a with() to push
and pop the include filename.
RP Modifications:
a) Split Include and Variable tracking
b) Replace deepcopy usage with dedicated copy function
c) Simplify some variable and usage
(Bitbake rev: b2dda721262da8abb7dc32d019e18fbc32ed8860)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If SkipParse is raised from something which isn't anonymous python, it wasn't
being handled correctly. This improves the handling for example from within inline
python.
(Bitbake rev: 7467d7d66b24cc8f43ab168e65895e7c4aee6092)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The inherits cache contains duplicate entries, some with the full patch, some
just starting classes/xxx. This is a waste of parse time and potentially
error prone. This patch fixes various pieces of code so the absolute paths are
always preferred and work correctly. The inherits_class function did not work
with full paths so the patch fixes this.
(Bitbake rev: f3a71e509af196391ec126d079cf1bd178e62ad5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current usage of EXPORT_FUNCTIONS is rather problematic since a class
list (classes) is passed into the ast statement and cached as it was
when first parsed. This class list may be different in other cases but
is locked once in the cache.
Worse, the construction of classes can be broken by exceptions during parsing
at the wrong moments since the state of the parser is not always reset
correctly. This can lead to leakage of other classes into the classes list.
The current EXPORT_FUNCTIONS implementation looks at the last two currently
inherited classes and sets up an indirect function call view the second last
class inherited, e.g.:
do_configure calls gnomebase_do_configure
gnomebase_do_configure calls autotools_do_configure
This intermediary doesn't seem to serve a useful purpose.
This patch therefore makes builds deterministic and fixes various cache problems
and indirection by removing the intermediaries and simply performing
directly mapping for the cases where its needed.
(Bitbake rev: 9fc98f96f0e0320beda0ce9546275a99336732c1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The classes variable in particular could be in an odd state if parsing of a
previous recipe had abruptly ended.
(Bitbake rev: 3dc5e896a97154914cee6c47900e3bb2a2627cdb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The data returned by get_file_depends() may me used in contexts like
checksums where order is important. The current usage of sets means
that some of the checksums can change in circumstances they should not.
This patch changes to use lists, thereby removing the problem.
(Bitbake rev: a44285fc4109236ab89f7aad0a1fc9220eec19b6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Syntax like:
FOO = "bar" # eek"
would result in FOO taking the value 'bar" #eek' which is clearly
not the intention. Whilst our metadata is riddled with mixtures of even
quotes like:
FOO = "d.getVar("X")"
odd numbers of quotes seem rare. This patch adds detection of one odd
quote which we don't have any of in OE-Core so it seems a valid sanity
improvement.
(Bitbake rev: 5f892d9b083550e20e37576070ec7d1a94cc88fe)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is useful if we need to disable part of one during a backtrace
for debugging purposes.
(Bitbake rev: 80a0c1b06a30a6ba9977c29fac0437a208d8cbbc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It was hard for me to understand what the define variable was, modulename
is hopefully a bit better.
(Bitbake rev: 79f9f46319de85f85613ebe248c327f5852225ba)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This removes some dubious functions and replaces them with a simpler, cleaner
API which better describes what the code is doing. Unused code/variables are
removed and comments tweaked.
(Bitbake rev: f1e943aebfb84e98253f3f21646d6765c4fa1d66)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This improves the stacktraces dumped by bitbake when for example anonymous
python functions fail.
Also default to passing code strings to better_exec to match the behaviour of
simple_exec to aid the transition.
(Bitbake rev: 7e8205929ae953731a6854ea80b197847cff5771)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Mixed spacing in python functions can cause subtle issues and
generally confuses users. We've standardised on 4 space indentation,
adding this warning helps ensure consistency and avoid bugs. It
also makes _prepend and _append operations on python functions slightly
less risky.
(Bitbake rev: c51cfaf48d3b12a19b01e824b6ba4230376bcad4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To make the UI settings take effect, we need to hook at the end of each
config file parsing and set UI specific values.
(Bitbake rev: f54e733c7863110896f43900d9e4e791602f9d65)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This means that statements that expand to more then one entry
such as:
CLASSES = "a b"
inherit ${CLASSES}
work correctly instead of trying to inherit a class called "a b".
(Bitbake rev: 2568e9ace6e6f483e1bf2a9ef2f4d8318d6c85b7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The export regexp was only meant to catch values like:
export VARIABLENAME
however after the stricter quoting patch was applied, it was also matching
variables like:
export BAR=foo
and setting the export flag on a variable called "BAR=foo". The = character
is an invalid variable name character. This patch tightens up the regexp
match so it only matches the intended character set and only matches variable
names.
(Bitbake rev: 6d1765c2eac8c1958ceb9c81d55d04a9bc961cb1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, bitbake will accept variables in the forms:
X = 1
X = '1 \
X = "1"
X = '1'
which will all set X=1. This patch removes the first two possibilities
and makes quoting mandatory. There is little metadata out there which
doesn't quote properly and bitbake will exit with an error about the
exact line number and file with any problem so users can easily identify
and fix issues. OE-Core has already been checked/fixed.
The motivation for this is being able to give sane errors if a user
does something like:
IMAGE_INSTALL += # tslib mtd-utils"
which currently gives a really nasty failure.
(Bitbake rev: a8ae80741fea5e0ec0fb9a52a963a4baa38d2564)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added new variable BBINCLUDED indicating the file dependency
information. It exposes the internal variable '__base_depends' and
'__depends'.
(Bitbake rev: af524a656fce32d01687481b86c31bef00eb9fc3)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ensure that a file and line number are reported for ParseError where
possible. This helps particularly in the case of inherit and require
which previously did not report either of these upon failure.
(Bitbake rev: f588ba69622a2df35417ced184e56c79ac1b40d5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Its possible for relative paths to creep into FILE. These confuse the
build system no end as its not clear where they might be releative to.
This patch ensures we always use resolved absolute paths for FILE
so that things behave in a deterministic way.
(Bitbake rev: 658d7daa70e46c2b20973b90ee53f0bbadc8bf5d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If metadata contains:
"""
FOO = "bar"
"""
The variable FOO should get set to "bar" but doesn't due to the empty lines
be swallowed by the parser and FOO becomming part of the multiline comment.
This patch corrects that behaviour so FOO is set as expected.
[YOCTO #1377]
This patch fixes parsing of multiline comments so lines ending with \
behave consistently and we warn users where there is something happening
they likely don't expect.
(Bitbake rev: 30eaef7f50fff855cf8830772a7088dd83a4240e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For multilib this produces variants of e.g. "multilib:lib64" instead of
just "lib64"; however we set BBEXTENDVARIANT to "lib64" and the latter
will be used when composing filenames for multilib.
(Bitbake rev: de7a2b91512bb3ab058f5eb5cd188acd2b8a2220)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When parsing multiline variables in conf files, the last character can
be accidentally removed. s2 contains new data read from the file which
may or may not end with the continuation character. It makes sense to
let the next loop iteration strip this if needed.
We don't often use multiline expressions in .conf files which is why I'd
imagine we haven't noticed this before. Most variables are quoted and
its the closing quotation which often disappears.
(Bitbake rev: 09a9146262d58dfe4a2ea4270026b90ae33f6c91)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As the code stands, setting a variable with ??= could result in a ?=
variable not overriding it. This patch fixes the issue by allowing
the ast to make lookups that ignore any ??= set variables.
(Bitbake rev: 32fee2e650dfdd3aa9a7572dad1251e0c24ca34b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add an optional argument to BBCLASSEXTEND entries which gets passed to
the extention class as BBEXTENDVARIANT. Also add BBEXTENDCURR whic
is set to the current extension class name.
This mode functions slightly differently to the previous BBCLASSEXTEND
code in that PN is not changed.
(Bitbake rev: 8d3c899e0a15840c54de26d2f1fc552430517778)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This means the event handler can change variables such as PN and those
changes will be reflected in the updated variable key names.
(Bitbake rev: 664b85742d1afc94b291a85fd245abebffacdf3d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
One of the implications is we need to register the event handlers before
executing the anonymous python functions. I can't find any issue with making
that change in any existing metadata use cases.
(Bitbake rev: a981df3cc9bf410d24f39919959952bdc6c76d03)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add skiplist to cooker that allows access to the list of packages skipped
via SkipPackage (this includes COMPATIBLE_MACHINE, INCOMPATIBLE_LICENSE,
etc.) This can be used to enhance error reporting.
(From Poky rev: 6c12b7b1099c77b87d4431d55e949cf7c5f52ded)
(Bitbake rev: 7d2363f35350be27a33f568c23eb07fcd3d27e53)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allows the heavy finalise function to only be run for the case we're
interested in when running tasks, saving some processing time.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, if a variable has been set with ??= and the code looks it up
before the data finalisation phase, no value is found. This is causes
serious problems for anonymous python functions which manipulate data, or
for the fetcher revision handling code where revisions can be set with
??=.
There is also a significant performance implication for processing lazy
assignment in finalise.
Moving the check for a default value into getVarFlag addresses both
the timing issue and the performace. This change gives a 7% real time
performance improvement to parsing the Poky metadata. The cost of the
check at this point is minimal since we have all the data flags available.
This should also fix Yocto bug 752.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We will be needing this information to improve the tracebacks of python code
from the metadata, as well as to give the user information about where
variables were defined, so they know how it ended up the way it is.
(Bitbake rev: 9615c538b894f71a2d1a0ba6b3f260db91e75786)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We can use the string split method for this instead.
(Bitbake rev: aa9646717b3ee1006628246a7c495f601e62391c)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We use a custom Logger subclass for our loggers
This logger provides:
- 'debug' method which accepts a debug level
- 'plain' method which bypasses log formatting
- 'verbose' method which is more detail than info, but less than debug
(Bitbake rev: 3b2c1fe5ca56daebb24073a9dd45723d3efd2a8d)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
These functions allow generation of dependency data between funcitons and
variables allowing moves to be made towards generating checksums and allowing
use of the dependency information in other parts of bitbake.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
to make updating depends easier/more intuitive/eventually faster
(Bitbake rev: f7c69462b8ba726861898817cc5b13174c78e35a)
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
This way we can fully utilize bblayers, you can do everything in bblayers.conf
and avoid setting any environment variables at all.
(Bitbake rev: 5def1c8c31432968349f9b29d6333d7962260a8b)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
As an example, this displays a deprecation warning for the use of
"bb.encodeurl" when you should be using "bb.fetch.encodeurl". It includes a
convenience function for this purpose. It should be of use when moving
objects between modules permanently, changing the API the user sees.
(Bitbake rev: 78f56049ba863b2e585b89db12b32697eb879bbc)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Apparently the finalise spelling is becoming less common in British English.
(Bitbake rev: 47449b2fc433e5725839ca4f7e9bca931a475838)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
The methodpool, ${@} expansions, anonymous python functions, event handlers
now all run with the same global context, ensuring a consistent environment
for them. Added a bb.utils.better_eval function which does an eval() with the
same globals as better_exec.
(Bitbake rev: 424d7e267b009cc19b8503eadab782736d9597d0)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
