| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
You can either:
a) switch to individual clones of bitbake, openembedded-core, meta-yocto and yocto-docs
b) use the new bitbake-setup
You can find information about either approach in our documentation:
https://docs.yoctoproject.org/
Note that "poky" the distro setting is still available in meta-yocto as
before and we continue to use and maintain that.
Long live Poky!
Some further information on the background of this change can be found
in: https://lists.openembedded.org/g/openembedded-architecture/message/2179
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move some environment variables to the configuration file, so there's
less happening in the class.
Max_size was removed so that the per-recipe caches don't grown without
limit. The default cache is 5GB.
(From OE-Core rev: 8c1c38a6b3073d2dd34514f5a90805c12c0f42dd)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When multiple recipes are built in parallel, Ccache sometimes refuses to
lookup some objects in cache, leading to undesired cache misses. The
root cause of this is an interaction between the way how bitbake
constructs a recipe sysroot and Ccache's `include_file_ctime` check.
Whenever bitbake creates a recipe's sysroot it hardlinks the files
provided by a recipes dependencies. Adding a hardlink to a file changes
it's ctime which in turn leads Ccache to believe that the file was
modified thus aborting the cache lookup.
To avoid this situation, add `include_file_ctime` to the list of checks
that should be ignored using the Ccache sloppiness configuration option
[1].
Example of a log entry that Ccache ignores a file:
/
|recipe-sysroot/usr/include/bits/pthread_stack_min.h had status change
|near or after invocation (ctime 1739822508.107677255, invocation time
|1739822507.970071107)
\
1 - https://ccache.dev/manual/4.10.2.html#config_sloppiness
(From OE-Core rev: 4899698297c7783e02aba5388e0469cc83bd2f70)
Signed-off-by: Fabio Berton <fabio.berton@criticaltechworks.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since ccache version 4.0, according to
https://github.com/ccache/ccache/blob/master/doc/NEWS.adoc#ccache-40
* An appropriate cache directory level structure is now chosen automatically. The cache_dir_levels (CCACHE_NLEVELS) configuration option has therefore been removed.
Therefore remove the option which has not been supported by ccache
recipe version since Yocto Hardknott.
(From OE-Core rev: 1d7c1b71e2639b8d069403920368292bd214347d)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
Fixed race issues when parallel build:
ccache: error: /path/to/ccache/i586-poky-linux/mmc-utils/ccache.conf: No such file or directory
ccache: error: /path/to/ccache/i586-poky-linux/mmc-utils/ccache.conf: No such file or directory
This is because we set CCACHE_DIR for earch recipe, and ccache will create a
ccache.conf for each CCACHE_DIR when CCACHE_CONFIGPATH is not set, but there
might be a race issue in parallel build:
ccache gcc file1.c
ccache gcc file2.c
If the two ccache processes use fopen(path, "w") to create ccache.conf at the
same time, the error would happen. Set CCACHE_CONFIGPATH to
meta/conf/ccache.conf can fix the problem, and we can add other configs to the
file when needed.
And also set cache_dir_levels to 1 (default is 2) since each recipe has a cache
dir, thus we don't have too many files in one dir.
(From OE-Core rev: 2abbc4d0cd571e82ed6188d3b2d84b4cd6be25e8)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
