add browser_tests in chromium_builder_dbg_drmemory_win target

add browser_tests in chromium_builder_dbg_drmemory_win target 
BUG=NONE 
R=timurrrr@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=209781

[Timur Iskhodzhanov, 2013-06-13 10:40:57]

I'm slightly out of context, so I'd like to ask a couple of questions before
reviewing.

1) Do you plan to set up browser_tests on the DrMemory bot we're using for base,
net, etc. or set up a new bot? If it's the former - how much time does it take
to run the subset?

2) How much additional time does it take to build/link browser_tests?

Per
http://build.chromium.org/p/chromium.memory.fyi/stats
the DrM builder and tester take ~45 minutes per cycle each, which is ~1.5h
commit-to-email notification delay.
I'd argue this is a lot already and we should use a separate pair of builder &
tester for browser_tests.

WDYT?

[zhaoqin, 2013-06-13 14:42:31]

On 2013/06/13 10:40:57, Timur Iskhodzhanov wrote:
> I'm slightly out of context, so I'd like to ask a couple of questions before
> reviewing.
> 
> 1) Do you plan to set up browser_tests on the DrMemory bot we're using for
base,
> net, etc. or set up a new bot? If it's the former - how much time does it take
> to run the subset?

We plan to move 6 bots for browser_tests from fyi to mfyi when it is ready.
We plan to only run a subset of the browser_tests, something like A* (66 test),
B* (128 tests).
we will make sure each bot as reasonable cycle time.

> 
> 2) How much additional time does it take to build/link browser_tests?
It should not be much if it is a component build, where most objects has been
built for unit_tests,
just an additional link to build browser_tests.
From my local machine, it is just a few mins difference, it is hard to tell how
much time would be on bots.
That's why we want to add it on builder first to see if the cycle time is ok,
and revert it if necessary.

> 
> Per
> http://build.chromium.org/p/chromium.memory.fyi/stats
> the DrM builder and tester take ~45 minutes per cycle each, which is ~1.5h
> commit-to-email notification delay.
> I'd argue this is a lot already and we should use a separate pair of builder &
> tester for browser_tests.

I understand for a component build is that most time is spent on building each
object file, it won't save much time if separate unit_tests and browsser_tests
as then share most object files.


> 
> WDYT?

[Timur Iskhodzhanov, 2013-06-13 14:57:10]

I see now, thanks.

LGTM if you already use component build on the builder.
Please watch the build time graph after committing!

You'll probably need an extra approval from one of the OWNERs?

[zhaoqin, 2013-06-13 15:49:37]

On 2013/06/13 14:57:10, Timur Iskhodzhanov wrote:
> I see now, thanks.
> 
> LGTM if you already use component build on the builder.
> Please watch the build time graph after committing!
> 
> You'll probably need an extra approval from one of the OWNERs?

hmm, it seems that the builder is not component build.
I will change it and use ninja to reduce the cycle time too.

[Timur Iskhodzhanov, 2013-06-13 16:05:58]

Please verify DrM works with component build first. I think we don't use
the component build for a reason?

[Reid Kleckner (google), 2013-06-13 16:11:03]

IIRC we fixed that some time ago because unit_tests was failing to link.
 Derek had to basically move mountains to get the debug dynamic CRT working.


On Thu, Jun 13, 2013 at 12:05 PM, Timur Iskhodzhanov
<timurrrr@chromium.org>wrote:

> Please verify DrM works with component build first. I think we don't use
> the component build for a reason?
>

[bruening, 2013-06-13 17:02:38]

On Thu, Jun 13, 2013 at 12:05 PM, Timur Iskhodzhanov
<timurrrr@chromium.org>wrote:

> Please verify DrM works with component build first. I think we don't use
> the component build for a reason?
>

Component has worked for some time.  Component is what we've been using on
our personal machines with Dr. Memory for a number of months now.

[commit-bot: I haz the power, 2013-07-02 16:27:01]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/zhaoqin@google.com/16836008/10001

[zhaoqin, 2013-07-02 21:48:11]

Committed patchset #2 manually as r209781 (presubmit successful).