Add chrome test support target to GN build.

Add chrome test support target to GN build.

Instead of putting all the files in a bit test_support target, I made separate smaller test support targets for the various sub-projects (browser, common, etc.) and linked those in. This helps distribute the complexity.

R=jamesr@chromium.org

Committed: https://chromium.googlesource.com/chromium/src/+/052ce13437f940da533740045acc70169243be27

[brettw, 2014-09-11 22:38:13]

brettw@chromium.org changed reviewers:
+ jamesr@chromium.org

[jamesr, 2014-09-11 22:56:34]

lgtm except for mojo/embedder/BUILD.gn which imo is wrong.  that's a source_set
that has to be part of a component (since it defines the _IMPLEMENTATION macro)
or it'll blow up

https://codereview.chromium.org/559543003/diff/20001/mojo/embedder/BUILD.gn
File mojo/embedder/BUILD.gn (left):

https://codereview.chromium.org/559543003/diff/20001/mojo/embedder/BUILD.gn#o...
mojo/embedder/BUILD.gn:6: # This isn't really a standalone target, it must be
linked into the
why'd you delete this? it's still true

[jamesr, 2014-09-12 01:11:18]

On 2014/09/11 22:56:34, jamesr wrote:
> lgtm except for mojo/embedder/BUILD.gn which imo is wrong.  that's a
source_set
> that has to be part of a component (since it defines the _IMPLEMENTATION
macro)
> or it'll blow up

Oops, I read the patch description again.  I still think that the visibility
rule is needed for the purpose of building since if someone declare a dep on
that they'll blow up, but maybe //mojo/system needs a way to forward header
visibility of //mojo/embedder ?  Do we have a syntax for that?

[brettw, 2014-09-12 16:25:26]

There are really 3 possibilities visibility:

1. You can't depend on or use anything from this target.
2. You can depend on and use any public headers from this target.
3. You can't depend on this target but you can use its public headers if you
somehow indirectly come to depend on it.

GN has only #1 and #2. My opinion is that the difference between #2 and #3 is
difficult to express clearly and is too subtle for casual users to understand
and use in a practical way. The main goal for visibility is to enforce API
boundaries which the existing binary mode supports.

If you really needed #3, it's possible to have no visibility but duplicate the
headers list in the public section of the "visible" target. This is pretty
inconvenient though.

[jamesr, 2014-09-12 16:30:39]

On 2014/09/12 16:25:26, brettw wrote:
> There are really 3 possibilities visibility:
> 
> 1. You can't depend on or use anything from this target.
> 2. You can depend on and use any public headers from this target.
> 3. You can't depend on this target but you can use its public headers if you
> somehow indirectly come to depend on it.
> 
> GN has only #1 and #2. My opinion is that the difference between #2 and #3 is
> difficult to express clearly and is too subtle for casual users to understand
> and use in a practical way. The main goal for visibility is to enforce API
> boundaries which the existing binary mode supports.

What if mojo/system said "I depend on mojo/embedder and I expose its public
headers" ?

> 
> If you really needed #3, it's possible to have no visibility but duplicate the
> headers list in the public section of the "visible" target. This is pretty
> inconvenient though.

[brettw, 2014-09-12 17:02:12]

I had a brainstorm and sent a proposal to gn-dev. I'll delete the visibility
changes in this patch since gn check doesn't pass now anyway.

[brettw, 2014-09-12 19:55:46]

Committed patchset #5 (id:80001) manually as 052ce13.

[commit-bot: I haz the power, 2014-09-12 19:55:48]

Patchset 5 (id:??) landed as
https://crrev.com/052ce13437f940da533740045acc70169243be27
Cr-Commit-Position: refs/heads/master@{#294641}