You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the initial macros change, Gradle will detect the task to be out-of-date but will reuse the compile state for each file as none of the files (source or headers) have changed. If the initial macros contain a macro participating in a macro include, the headerDependencies will be wrong as the graph will be reused on the basis that no files changed. The third build will be up-to-date as no file changes, and the initial macros haven't changed. In this case, the wrong header graph will be reused again. Suppose the build code containing the new initial macros is committed; any new workspace will compute a different header graph, making the cache key incompatible with the original build. Note that the second build can also corrupt the build cache by providing the result of a compilation for the wrong cache key. The chance of this particular case happening is very slim, but it would still affect the correctness of the build.
The simplest patch is to include the initial macros inside the compile state. However, this approach may over-invalidate as not all initial macros may participate in the header discovery.
A more complicated patch would require tracking which macros affect the header discovery and tracking only those initial macros. The file hashing covers any macros found during the discovery process.
The macros passed by the compiler arguments are not currently taken into account. The same is true for the default includes and macOS framework headers.
The text was updated successfully, but these errors were encountered:
If the initial macros change, Gradle will detect the task to be out-of-date but will reuse the compile state for each file as none of the files (source or headers) have changed. If the initial macros contain a macro participating in a macro include, the
headerDependencies
will be wrong as the graph will be reused on the basis that no files changed. The third build will be up-to-date as no file changes, and the initial macros haven't changed. In this case, the wrong header graph will be reused again. Suppose the build code containing the new initial macros is committed; any new workspace will compute a different header graph, making the cache key incompatible with the original build. Note that the second build can also corrupt the build cache by providing the result of a compilation for the wrong cache key. The chance of this particular case happening is very slim, but it would still affect the correctness of the build.The simplest patch is to include the initial macros inside the compile state. However, this approach may over-invalidate as not all initial macros may participate in the header discovery.
A more complicated patch would require tracking which macros affect the header discovery and tracking only those initial macros. The file hashing covers any macros found during the discovery process.
The macros passed by the compiler arguments are not currently taken into account. The same is true for the default includes and macOS framework headers.
The text was updated successfully, but these errors were encountered: