Hmm, why did that not happen for Android bots, which also have host and target toolsets? All the upstream and downstream bots digested crrev.com/1675143004 fine.

This is warning that the build may not be deterministic, not an error so it won't cause any bot failure. In addition, many of the android bots uses gn that correctly generate the header in different directories when using different toolchain.

However, we can see that android bots that uses gn exhibits the same problem, see for example this log: https://build.chromium.org/p/tryserver.chromium.android/builders/android_compile_dbg/builds/33379/steps/compile%20%28with%20patch%29/logs/stdio

ninja -C /b/build/slave/android/build/src/out/Debug android_webview_test_apk android_webview_unittests_apk base_junit_tests base_unittests_apk blink_heap_unittests_apk breakpad_unittests_deps cc_unittests_apk chrome_junit_tests chrome_public_apk chrome_public_test_apk chrome_sync_shell_test_apk components_browsertests_apk components_junit_tests components_unittests_apk content_browsertests_apk content_junit_tests content_shell_test_apk content_unittests_apk cronet_test_instrumentation_apk device_unittests_apk events_unittests_apk gl_tests_apk gl_unittests_apk gpu_unittests_apk ipc_tests_apk junit_unit_tests media_unittests_apk net_junit_tests net_unittests_apk sandbox_linux_unittests_deps sql_unittests_apk sync_unit_tests_apk system_webview_apk ui_android_unittests_apk ui_base_unittests_apk ui_junit_tests ui_touch_selection_unittests_apk unit_tests_apk -j50
ninja: Entering directory `/b/build/slave/android/build/src/out/Debug'
ninja: warning: multiple rules generate gen/base/allocator/features.h. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]

Ok I will have a chat with brett to figure out the options.
Unfortunately I didn't see this when testing locally.
Worst case, I guess we can make that target-only, unles I am missing something I don't think we have a compelling need of having the shim on host artifacts.
IIRC they are not shipped and used just as part of the build.

I think we should be able to make this target only and everything will be OK.

will do

Oh, I remember I this for base.gyp:debugging_flags.

When you make this change, it's important that you find all references to the target and change them to '...#target' dependencies or everything will break.

SG. IIRC there are really only two places that depend on this, should be fairly easy.
Will do as first thing monday morning.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d19a104896da1904ac7b013a5cd6b4ffc205098d

commit d19a104896da1904ac7b013a5cd6b4ffc205098d
Author: primiano <primiano@chromium.org>
Date: Tue Mar 15 19:47:28 2016

Make the allocator_features gyp target target-only

allocator_features uses buildflag_header to generate a header at
build time. In host/target builds, both the #host and #target
targets have a ninja rule for the same path, which is bad.
This CL makes allocator_features follow the same pattern of
base_debugging_flags (target-only, everything else explicitly refers
to the #target veriant)

I verified that the problem reproduces without this patch
by doing:
$ build/gyp_chromium -DOS=android -Duse_experimental_allocator_shim=1
$ ninja -w dupbuild=err -n -C out_android/Release/ all
ninja: warning: multiple rules generate gen/base/allocator/features.h. builds involving this target will not be correct;

And this CL fixes it.

BUG= 593695 

Review URL: https://codereview.chromium.org/1794943006

Cr-Commit-Position: refs/heads/master@{#381289}

[modify] https://crrev.com/d19a104896da1904ac7b013a5cd6b4ffc205098d/base/allocator/allocator.gyp
[modify] https://crrev.com/d19a104896da1904ac7b013a5cd6b4ffc205098d/base/base.gyp