We no longer need index/workdir support in the mirror tree and it causes all
kind of reference naming problems.Simplifying the code to remove this and use
just bare clones addresses this problem.
We increase the "version" number on the mirror tarballs to reflect the change
and ensure older mirror tarballs are not used as they would break.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since local mirror fetches are always symlinked from the download directory
directly, there is no need for this premirrors hack which doesn't cover
mirrors and also abuses the localpath variable with inconsistent results.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When files are fetched from a mirror source that happens to be local,
ensure links are created for the file since subsequent fetch calls
can then follow the links to find files.
Any other approach such as the existing manipulations of localpath
internally to the fetcher are prone to errors, races and other issues.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When processing a cvs SRC_URI to a file:// mirror, the user and host information
will break the mirror processing. This patch addresses it by only constructing
valid urls.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* SRC_URI format:
the SRC_URI are extended to allow multiple src rev:
name=<name1>,<name2>,...<name-n>
branch=<branch1>,<branch2>,...,<branch-n>
also SRCREV can be defined with
SRCREV_<name1> = xxxxx
SRCREV_<name2> = xxxxx
* FetchData extention
to support multiple src rev, several FetchData data are added:
- FetchData.names: list of name in SRC_URI, one name per srcrev. name is the index of revision and branch
- FetchData.revisions: dictionary of name->revision.
- FetchData.branches: dictionary of name->branch.
For example, linux-yocto recipes becomes:
SRC_URI = "git://git.pokylinux.org/linux-yocto-2.6.37;protocol=git;branch=${KBRANCH},meta;name=machine,meta"
FetchData.names = ['machine', 'meta']
FetchData.revisions = { 'machine':xxxxx, 'meta':xxxxxx }
FetchData.branches = { 'machine':${KBRANCH}, 'meta':'meta'}
* generic revision handling extension
the related revision handling code in fetch2.__init__.py are changed accordingly. the major change is add name parameter to indicate which src rev to handling. originally there is one src rev per FetchData, so FetchData parameter is enough. now since one FetchData has multiple src rev, it is necessary to use FetchData + name to specifiy src rev.
* git extension
git fetcher are also revised to take advantage of the multiple src rev in FetchData. especially the download() method are enhanced to fetch multiple src rev.
* other fetcher (svn, hg, ...) does not support multiple src rev. they just sync the API to add name, and then simply ignore the name. no actually functional change
Signed-off-by: Yu Ke <ke.yu@intel.com>
Since we're now always providing the git source control files it becomes
pointless to handle the tarballs of specific git revisions so drop this
part of the fetcher.
Signed-off-by: Yu Ke <ke.yu@intel.com>
The git download method clones the git repository to the local machine. The unpack process
can be optimised to be a local to local machine clone or a direct readtree operation to the
destination using git.will clone git repo to local, so git unpack can be simplified
to only checkouting the code to the work dir. For fullclone case, we also
need to manually copy all the ref info, which is needed by the later do_kernel_checkout().
Rather than use hardlinks, we reference the repository using alternatives since the
download directory may be on a different filesystem.
[Change to use -s by Richard Purdie]
Signed-off-by: Yu Ke <ke.yu@intel.com>
The server UI was reading 1024 bytes, then sleeping for 0.25 seconds. Since
most new LogRecord events are larger than this it leads to a build up of data
which is only processed slowly, leading to a bottleneck and a slow down of
all bitbake processes.
Thanks to Dongxiao Xu <dongxiao.xu@intel.com> for the great work in debugging
this. A large value has been left in for the read() command just to ensure some
fairness amongst process handling if a task tries to log truly huge amounts of
data to the server, or goes crazy and ensures the main loop doesn't stall.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sometime user want a purely local fetching, i.e. using local mirror without
any remote netowrk access. BB_NO_NETWORK option is introduced for this purpose
check_network_access() is the guard for BB_NO_NETWOKR option. it should be
put in any place that fetcher use network access
Signed-off-by: Yu Ke <ke.yu@intel.com>
the download is to fetch the source from URL, the build_mirror_data is
to create the mirror tar ball. the original go() method mix them together,
it is more clean to split them.
Signed-off-by: Yu Ke <ke.yu@intel.com>
there is case that we need to distingush bb.fetch and bb.fetch2,
and use different API for bb.fetch and bb.fetch2. so it is necessary
to add version info for distinguish purpose
Signed-off-by: Yu Ke <ke.yu@intel.com>
change the unpack to use the urldata and rootdir parameter
- urldata is the FetchData instance
- rootdir is the dir to put the extracted source. the original unpack
use current dir (os.getcwd) as destination dir, which is not flexible
and error-prone (error will occur if caller not chdir to dest dir)
Signed-off-by: Yu Ke <ke.yu@intel.com>
current bitbake-diffsigs simply print out the whole 'runtaskdeps' when there's mismatch, which
is not very readable. On the other hand, 'runtaskhashes' comparison is broken which assumes
same key existing in two sides. This commit provides better output by figuring out differences
from addition, removal or hash change.
Signed-off-by: Kevin Tian <kevin.tian@intel.com>
Take a real world testcase where you have two recipes, each of which
contains PACKAGES_DYNAMIC = "gdk-pixbuf-loaders-*" and recipes which
RDEPEND on some gdk-pixbuf-loaders-xxx package. To select between these
you need to set a PREFERRED_PROVIDER.
These are specified in the PN namespace so the locgical conclusion is
that setting PREFERRED_PROVIDER_gdk-pixbuf = "gtk+" should work. It
doesn't and instead checks crazy things.
The code was correctly finding the two possible providers, gtk+ and
gdk-pixbuf. It was however only accepting PREFERRED_PROVIDER_gtk+
= "gdk-pixbuf" to resolve this problem which reads as the exact
opposite to what was wanted.
This patch changes the code to do something that makes sense. I suspect
that before these changes it was pretty much a null operation rubber
stamping the single provider case. For Poky at least it exposes a few
cases where -nativesdk recipes were providing the same things as their
normal counterparts but these are genuine bugs in the metadata.
I've also attempted to make the multiple provider error message human
readable as I counldn't understand it and I doubt anyone else could
either.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For certain tasks, we need additional information in build stamp file
other than the task name and file name. stamp-extra-info is introduced as
a task flag which is appended to the stamp file name.
[Code simplifcations/tweaks from Richard]
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Even when a variable was whitelisted, any dependencies of that variable
could still creep into the task hash due to the way the whitelisting
code worked. This patch changes thing to ensure that when whitelisted,
that whitelisting applies to the variable and any dependencies it has.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We had a logic inversion that meant we where dropping quite a
significant number of events on the floor.... Fixed!
Signed-off-by: Joshua Lock <josh@linux.intel.com>
It's unlikely that someone wants to close the progress dialog
yet leave the UI (and BitBake process) running, so hook up
the progress dialogs delete-event to exit gtk.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
The recent change to Queue up events before the UI is spawned (in
26eda93337) broke the xmlrpc server because the
uievent implementation of BBUIEventQueue expects pickled strings for its
queue_event() method.
This is because the RPC exposed event.send() method must accept pickled
strings, but for xmlrpc event.send() is just mapped to queue_event().
Work around this by adding a send_event method which unpickles strings and
hands them off to queue_event() which can then be used for the remapping.
Signed-off-by: Joshua Lock <josh@linux.intel.com>
It turns out that while log filters added with addFilter are only associated
with that logger, and not its children, handlers are inherited, and handlers
can be filters. So, let's add filtering to our existing LogHandler class
which dispatches our log records as bitbake events.
(Bitbake rev: 0153ace246e7c88366f45c8f035a2b4505a1c115)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
we should cache SRCREV whenever possible, the only exception is
when SREREV is auto rev. so change the logic to only set __BB_DONT_CACHE
at SRCREV = "${AUTOREV}" case
Signed-off-by: Yu Ke <ke.yu@intel.com>
Current fetcher has annoying "SRCREVINACTION" deadlock,
which occurs when SRCREV=${AUTOREV}=@bb.fetch.get_srcrev():
get_srcrev()->setup_localpath()->srcrev_internal_helper()
->evaluate SRCREV->get_srcrev()
current fetcher resolve the deadlock by introducing a
"SRCREVINACTION" condition check. Althoguh it works, it is
indeed not clean.
This patch use antoehr idea to break the deadlock: break
the dependency among SRCREV and get_srcrev(), i.e. assign
a specific keyword "AUTOINC" to AUTOREV. when Fetcher meet
this keyword, it will check and set the latest revision to
urldata.revision. get_srcrev later can use the urldata.revision
for value evaluation(SRCPV etc). In this case, SRCREV no longer
depends on get_srcrev, and there is not deadlock anymore.
Signed-off-by: Yu Ke <ke.yu@intel.com>
FetchData has some fetch method specific data, and only fetch method knows how
to initialize it. originally it is mostly initialized in Fetch.localpath().
But now there is requirement to call Fetch.latest_revision() before
Fetch.localpath(), thus require another earlier place for initialization. so
urldata_init is introduced for this purpose. it will be called in FetchData:__init__
and make all the Fetch functions useable after that.
Signed-off-by: Yu Ke <ke.yu@intel.com>
bb.fetch2 is copied from bb.fetch, and has many bb.fetch referrence.
Fix these referrence with bb.fetch2 referrence
Signed-off-by: Yu Ke <ke.yu@intel.com>
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>
Errors can result from these expansions, but for skipped recipes, we
shouldn't care about those failures. This fixes the same issue which
Richard Purdie fixed in poky, commit 847b717.
(Bitbake rev: 96ee6840010c1ae1080e6bf7ff0f4eb2d361e84b)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This cleans up the knotty console messages to be a lot quieter and cleaning,
in keeping with the expectations of most users.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[BUGID# 645], modify the emit_var()
1. Added "#" to the beginning of each line if the comment contains
multiple lines.
2. Added "\" to the end of each line if the shell variable value
contains multiple lines.
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
The current parameters are not useful to the stampfile generator function
as they can't uniquely define a task. This updated things so the
parameters can identify unique tasks.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Move stamp file deletion out of the internal stamp helper function
* Add a new function to return the path to a stamp for a given task
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>
This ensures that when a failure occurs very early on in bitbake startup, the
message formatting ematches that used by the UIs.
(Bitbake rev: c8ff0fd3e9f050a668f1a069cf37ee37db3664fa)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I think this is less confusing, and avoids needing to know about the *range*
of logging levels, instead simply asking what we really want to know.
(Bitbake rev: dc2264387617586b5c0a61e126c75edde5e7abcd)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The various alternative UIs have been updated to once again be functional
with the latest bitbake internals. Each of the UIs still have much room for
functional improvement.
In particular, they have been updated to:
- interact with the new process based server
- handle the current set of events and notifications fired from the server
and its associated subsystems
(Bitbake rev: b947e7aa405966262c0614cae02e7978ec637095)
Signed-off-by: Bob Foerster <robert@erafx.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
python tasks calling shell functions using exec_func() would show the log
file as /dev/null. It makes most sense for all the task logging to be setup
centrally by exec_task(), at least with the current code base in Poky.
This commit will need discussion in relation to upstream bitbake and the
IO redirection could be better handled using a context manager (although
task contexts shouldn't ever nest).
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Think this got inadvertantly dropped when switching to the new API.
(Bitbake rev: 628c5159d1151b89f2b7210c8819489e8dc9a84d)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Rather than having to run .addDomain() and then .getValue(domain, key),
.setValue(domain, key), etc, now it just works as mappings.
As an example:
setValue(domain, key) -> persist[domain][key] = value
It also arranges things so we can construct objects of this type using any
arbitrary filename/path for the sqlite3 database, rather than being so
tightly bound to the metadata.
(Bitbake rev: d9e8b8af308ae871efdc8ef0782be30af8c1f894)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Caching the database connection can cause serious issues if it results in
multiple processes (e.g. multiple tasks) simultaneously using the same
connection.
This reverts commit 8a6876752b90efd81d92f0947bfc9527d8260969.
(Bitbake rev: 60b9b18eafad5ac46c7cf1048d749d673c2ee0ad)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Only mark fn as clean if it is clean.
This saves us from removing (prematurely added) fn from our clean set
and saves me a few percent of runtime (and misleading debugging output
from remove()).
(Bitbake rev: 884365228fcaac07421ac1440d4946693fb628c5)
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Previously we emitted two newlines for export and unexport.
One newline for export and unexport is enough (and makes the scripts
look better and a tad smaller).
(Bitbake rev: ba060160fdf1278a273fb2b77d36b8c681807ecf)
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
When using a logfile, we weren't sending input to the child process.
(Bitbake rev: 5ec4ca7e45bdf6d259503fc67155395e89ba6329)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Without sorting, it's very difficult to find the information you're
looking for. Now, the lists are all sorted alphabetically for easy
viewing.
(Bitbake rev: 80e3d3a130b9dee72c11c6946bb5ff7705111d7c)
Signed-off-by: Bob Foerster <robert@erafx.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
(Bitbake rev: bdd7813d8eecf7b6b636322e748ca6bf69118513)
Signed-off-by: Bob Foerster <robert@erafx.com>
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
(Bitbake rev: f42e6d33b986183eee2c74aa7b1bbc9b339276a9)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* Allows generating version information from SCMs during build.
* Note that tar doesn't need to use --exclude '.git', because
git checkout-index doesn't clone the repository.
(Bitbake rev: 05cbc1d1a01c667c77688f36fbc5b61c5f452a3a)
Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
The previous attempt was incorrect. The issue isn't that subprocess fails to
set PWD, it's that PWD is in the metadata, inherited from the environment, and
is re-exported, overwriting the actual accurate one in the shell environment
with the old one from the metadata. So, ensure that PWD in the metadata is
not exported.
We can ditch this when the environment handling is reworked (e.g. poky's
commit to do so).
(Bitbake rev: 2c8683234acf514706b2b69f5b29405485e664dd)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
- Moved the logic for comparing revisions from cooker into command
- Removed 'Cooker' from the event names
- Renamed the 'ExitCode' event into CommandExit, and changed CommandFailed to
be a subclass of CommandExit
(Bitbake rev: c51ed5d7a9971fad6019dac6c35a71b8a54ab16a)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
We now wrap the main() in a try/except, ensuring that both the main portion of
bin/bitbake and the UI raising an exception will be shown to the user. For
the server and workers, we can ensure in the server itself that exceptions are
handled correctly.
(Bitbake rev: 240d4a7ae80a6636c302ae84266ddfed7a7fcedd)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Also don't bother passing logfile to exec_func_python, at least until we start
adding the logfile as a file handler to the bitbake logger.
(Bitbake rev: f99ee4680c9f67b7ed13fc06044ba2382f9a782c)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
(Bitbake rev: 53740977521bc81ffa37adfa7bbeb8f2a80ea165)
build: write logfiles per task, not per function
Based on d14f9bf6 from poky, reworked for master and other cleanup.
(Bitbake rev: beadff2eca1eb95f0411115dd72ddb4c3c44c604)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
As these may run the UI in a blocking fashion and then return the exit code,
'init' was an inappropriate name, and 'main' is more appropriate.
(Bitbake rev: 4d081a0ed759bd526ab01849d650bd9e8d80ddd1)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
We want to match the requested pattern at the beginning of the string,
otherwise things behave in an unintuitive manner wrt ASSUME_PROVIDED (e.g.
ASSUME_PROVIDED += "gtk+" will also assume foo-gtk+ is provided), and the user
can always use '.*gtk+' to get the old behavior.
(Bitbake rev: 5670134ab2eb573d39df3c3231677cdb1a1dfc72)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Rather than updating the progress bar based on the recipe being processed
(whether cached or parsed), consider only parsed recipes. This reduces the
instability in progress rate introduced by the cached entries, and allows the
ETA to be resurrected and be a bit more useful.
(Bitbake rev: 618480f7739f6ae846f67a57bee5a78efb37839d)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Currently, the progress bar is an indication of the processing of our recipes,
which includes loading the cache file, then for each recipe, either adding the
existing cached information to the CacheData or parsing the recipe from disk.
These tasks clearly take different amounts of time, so the ETA is unreliable
today. We'll resurrect this functionality after we revamp the progress
handling, fully incorporating the load of the cache file.
(Bitbake rev: 80867372dcbef91ebaf7d77a77ca871741dd3f74)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Without explicitly joining the thread, it's possible for the process to end
(e.g. after a bitbake -p) and kill off the thread without waiting for it to
exit cleanly. So, register the thread join with atexit.
(Bitbake rev: 97ce57e6f860d3e6f34cc7a603ed1eeac4f423d3)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
This ensures that the time spent loading the cache from disk occurs with the
progress bar up. Though the progress bar stays at 0% during this period, I
think this is an improvement over the multi-second stall which occurred
previously before the progress bar came up. Ideally, we'd integrate cache
loading from disk into the progress display, but this is a first step.
(Bitbake rev: f6d0a5c219f9deb84f702450d30d868ba6271f77)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Previously, the cache was actually being loaded from disk twice whenever using
-b or -e -b. This also moves the bb_cache instance into the CookerParser, as
it's not needed by the cooker itself at all.
(Bitbake rev: dd0ec2f7b18e2a9ab06c499b775670516bd06ac8)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
This version uses a thread rather than a process, to avoid problems with
waitpid handling. This gives slightly less overall build time reduction than
the separate process for it did (this reduces a -c compile coreutils-native by
about 3 seconds, while the process reduced it by 7 seconds), however this time
is quite insignificant relative to a typical build.
The biggest issue with non-backgrounded syncing is the perceived delay before
work begins, and this resolves that without breaking anything, or so it seems.
(Bitbake rev: 5ab6c5c7b007b8c77c751582141afc07c183d672)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Rather than adding nocache items to the cache, then copying the cache and
removing them to sync it, don't add them in the first place. Also use 'with'
for the cachefile.
(Bitbake rev: 343b6f6255ad020c39e30742175a241f0859a5a6)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
This utilizes python's multiprocessing module. The default number of threads
to be used is the same as the number of available processor cores, however,
you can manually set this with the BB_NUMBER_PARSE_THREADS variable.
(Bitbake rev: c7b3ec819549e51e438d293969e205883fee725f)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
If the only recipes's we reparsed this run were those flagged as not to be
cached, there's no point in re-saving the cache, as those items won't be
included anyway.
(Bitbake rev: 1e0c4dbcbec886a30b89f8b4bb365c3c927ef609)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
This class holds the particular pieces of information about a recipe which are
needed for runqueue to do its job.
By using it, I think we improve code clarity, reduce method sizes, reduce
overuse of primitive types, and prepare for parallel parsing. In addition,
this ditches the leaky abstraction whereby bb.cache attempted to hide the
difference between cached data and a full recipe parse. This was a remnant
from the way things used to be done, and the code using it had to know the
difference anyway. If we choose to reimplement caching of the full recipes,
we can do it in bb.parse, in a completely transparent way.
(Bitbake rev: 992cc252452221f5f23575e50eb67528b2838fdb)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
range() allocates an actual list when called. xrange() is just an iterator
and creates the next range item on demand. This provides a slight
performance increase.
In python 3, range will do what xrange does currently, but the upgrade will
be handled by the 2to3 tool.
(Bitbake rev: 73b40f06444cb877a5960b2aa66abf7dacbd88f0)
Signed-off-by: Bob Foerster <robert@erafx.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
1) too spammy
2) can be implemented in the metadata instead
This reverts commit 8da9744fcdf856abebcfbe9e3bc1b8cf07bc317b.
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
as noted by rp in ac00ca89a4e43cd4f38ba86455079d31be78e644
(Bitbake rev: 8da9744fcdf856abebcfbe9e3bc1b8cf07bc317b)
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
no functional changes
(Bitbake rev: e88834fb7c6821cc29c12d296f2edd51f6eb3746)
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Several fetcher need a way to strip leading slashes off a local path.
This helper-function consolidates all such occurances.
(Bitbake rev: 823a02185ed109054c6c1ae366221aaed0353f24)
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
osc had it already spelled correctly?!
(Bitbake rev: b8bb4433de7a981c6826173e926ca34705c4ac70)
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
If a recipe depends on a file, and that file is out of date, we show a
message, but if that file was removed, we do not, until now.
(Bitbake rev: 67984ba0ac2db79874541bc031f2e3e9ff7a6c32)
Signed-off-by: Chris Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Richard Purdie
Saul Wold
Yu Ke
Kevin Tian
Dongxiao Xu
Bernhard Reutner-Fischer
Joshua Lock
Chris Larson
Lianhao Lu
Richard Purdie
Bob Foerster
Bob Foerster
Andreas Oberritter