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: 22e6b1c4c4afb27057689bbc94cbdf1f19f93e3d)
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>
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>
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>
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 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>
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>
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 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>
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>
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>
This ensures that an anonymous python function is able to manipulate the
BBCLASSEXTEND contents, and, therefore, amend.inc files are able to add to it.
(Bitbake rev: c7d038d404afaf4ce3735af5134163759da6f6ef)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Do not attempt to open the file in the resolve_file method
(a lot like bb.which... maybe bb.which can be used). This way
we don't need to open/close a file which we have already parsed.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Have a growing dict with .inc and .bbclass'es. This avoids to reparse
files we have already seen.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Our parser is shit but instead to replace it now we will see
how long we can drive the wave by caching parsed files. This
will not go through the feeder again but we can just reevaluate
the StatementGroup.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Evaluate the statements after having parsed one file. This is
referred to as "entwirren" and we can remove the direct evaluation
and postpone a bit, in the future we can use a cached copy instead
of parsing the original.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
When parsing we will collect a number of statements
that can be evaluated...The plan is to be evaluate
things twice (old+new) and then compare the result,
it should be the same.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* lineno and fn are needed in handleMethod
to restore the functionality as it was before.
(Bitbake rev: ac6792045959cfee56279c1c4597521e990848e7)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Chris Larson <clarson@kergoth.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Richard Purdie
Paul Eggleton
Robert Yang
Yu Ke
Chris Larson
Bernhard Reutner-Fischer
Richard Purdie
Chris Larson
Holger Freyther
Chris Larson
Khem Raj