3.2.4.2. Invalidating Shared State

-3.2.4.2. Invalidating Shared State

- The shared state code uses checksums and shared state - cache to avoid unnecessarily rebuilding tasks. - As with all schemes, this one has some drawbacks. - It is possible that you could make implicit changes that are not factored - into the checksum calculation, but do affect a task's output. - A good example is perhaps when a tool changes its output. - Let's say that the output of rpmdeps needed to change. - The result of the change should be that all the "package", "package_write_rpm", - and "package_deploy-rpm" shared state cache items would become invalid. - But, because this is a change that is external to the code and therefore implicit, - the associated shared state cache items do not become invalidated. - In this case, the build process would use 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 - change you make. - Note that any changes you make directly to a function automatically are factored into - the checksum calculation and thus, will invalidate the associated area of sstate cache. - 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. - Once you are aware of such a change, you can take steps to invalidate the cache - and force the task to run. - The step to take is 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. - The change is purely cosmetic, but it causes the checksum to be recalculated and - forces the task to be run again. -

Note

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