See  bug 736215  for background and discussion.

In particular:

"if your change affects a target that is built with one of the alternate toolchains, then GN returns the label of that toolchain from analyze (e.g., `//chrome/android:monochrome(..android_clang_arm)` rather than `//chrome/android:monochrome`; however, (a) MB doesn't know how to deal with translating the toolchain part of the label back into the matching ninja target, partially because (b) GN doesn't generate phony targets for targets in alternate toolchains.

This shows up most commonly in the android monochrome builds (which build lots of things for both arm32 and arm64), but will also show up in the x86 windows build (where we build some things for both x86 and x64), and can potentially show up even for things in other toolchains.

The right long-term fix is probably to make GN return the output paths for the targets in `compile_targets`, rather than the labels; however, that'll be an interface change so we might want to use a flag to control this."