commit 77497817b011f298b7f3a1138b08ba6a962b24b8
author juliexxia <juliexxia@google.com> Fri Jul 19 13:49:48 2019 -0700
committer Copybara-Service <copybara-worker@google.com> Fri Jul 19 13:50:55 2019 -0700
tree 242ff9229983622f3fb68e418643fe2564494389
parent 031db8ee77ba608806515d1c1efa3f344ae52be1

Make transitionDirectoryNameFragment a hash of the following
(1) names and current values of all native options that have been touched by starlark transitions so far in the build*
(2) names and current values of all starlark options in map that have different values from the command line configuration.
(3) names and current values of all options affected by current transition (already encompassed by (1) and (2), but explicitly noting for clarity)

This ensures that the hexDigest is only keeping track of new states that are actually different from the previous state i.e. the most recent transition actual creates a different configuration from the last transition.

Previous logic hashed all changes in current transition and appended has onto previous hash -> broke directly building outputs of targets with starlark rule class transitions.

*In the case that we have the sequence StarlarkTransitionFoo set optionA="blah" -> NativeTransitionFoo set optionA="woof", we still include optionA="woof" in the hash. This value is potentially already reflected elsewhere in the buildmnemonic[1] because it could be used to compute its fragment's output directory string, but we're willing to accept this potential overlap for sake of simplicity+correctness. Fragments compute their output directory strings however they want, so we have no guarantee that any given option is included in its fragment's output directory computation (and according to gregce@, generally low fraction of options per fragment are used).

It's important to note that the strategy in this CL isn't optimal. If you look at StarlarkAttrTransitionProviderTest, you can see examples of situation where two identical configurations end up with different hashes because of this hashing strategy. This mostly stems from build setting defaults not being stored in the starlark options map, not knowing all top level configuration values, not wanting to have a hash for outputs in the command line configuration, etc. But this should be *correct* in the sense that two configured targets with genuinely different configurations will not have the same hash (which could lead to action conflicts).

Along the way, also only trigger pre- and post-work relevent to starlark transitions IFF there's a starlark transition being applied.

TESTED=devblaze build experimental/users/kaipi/blaze:rule_class_transition.output
PiperOrigin-RevId: 259031426