From ae06e04cd225d2c2147ca355e2dd39b4f6cf6775 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 29 Jan 2018 15:18:03 -0800 Subject: documentation: Created new "Getting Started" manual. Creation involved removing the overview-manual and replacing it with the getting-started manual. All links to the string "&YOCTO_DOCS_OVERVIEW_URL" had to be replaced with "&YOCTO_DOCS_GS_URL" across the entire YP manual set. I renamed files used to create the manual with prefixes suited for the new manual name, which is "Getting Started With Yocto Project". The style sheet for the new manual needed updating to display the new .PNG image for the title page. The mega-manual file had to be updated to include the files. The mega-manual.sed file had to be updated to include the new manual and not use the overview manual. (From yocto-docs rev: 6c7abf9192390121000f577d6c98f259d290d15d) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- .../getting-started/invalidating-shared-state.html | 77 ++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 documentation/getting-started/eclipse/html/getting-started/invalidating-shared-state.html (limited to 'documentation/getting-started/eclipse/html/getting-started/invalidating-shared-state.html') diff --git a/documentation/getting-started/eclipse/html/getting-started/invalidating-shared-state.html b/documentation/getting-started/eclipse/html/getting-started/invalidating-shared-state.html new file mode 100644 index 0000000000..ef4a2aac5e --- /dev/null +++ b/documentation/getting-started/eclipse/html/getting-started/invalidating-shared-state.html @@ -0,0 +1,77 @@ + + + +3.3.4.2. Invalidating Shared State + + + + + + + +
+

+3.3.4.2. Invalidating Shared State

+

+ The OpenEmbedded build system uses checksums and shared + state cache to avoid unnecessarily rebuilding tasks. + Collectively, this scheme is known as "shared state code." +

+

+ As with all schemes, this one has some drawbacks. + It is possible that you could make implicit changes to your + code that the checksum calculations do not take into + account. + These implicit changes affect a task's output but do not + trigger the shared state code into rebuilding a recipe. + Consider an example during which a tool changes its output. + Assume that the output of rpmdeps + changes. + The result of the change should be that all the + package and + package_write_rpm shared state cache + items become invalid. + However, because the change to the output is + external to the code and therefore implicit, + the associated shared state cache items do not become + invalidated. + In this case, the build process uses the cached items + rather than running the task again. + Obviously, these types of implicit changes can cause + problems. +

+

+ To avoid these problems during the build, you need to + understand the effects of any changes you make. + Realize that changes you make directly to a function + are automatically factored into the checksum calculation. + Thus, these explicit changes invalidate the associated + area of shared state cache. + However, you need to be aware of any implicit changes that + are not obvious changes to the code and could affect + the output of a given task. +

+

+ When you identify an implicit change, you can easily + take steps to invalidate the cache and force the tasks + to run. + The steps you can take are as simple as changing a + function's comments in the source code. + For example, to invalidate package shared state files, + change the comment statements of + do_package + or the comments of one of the functions it calls. + Even though the change is purely cosmetic, it causes the + checksum to be recalculated and forces the OpenEmbedded + build system to run the task again. +

+
+

Note

+ For an example of a commit that makes a cosmetic + change to invalidate shared state, see this + commit. +
+

+

+
+ -- cgit v1.2.3-54-g00ecf