Move base GN subprojects into base.

Move base GN subprojects into base.

These were all subprojects to keep the build files closer to the source, as is GN style.

However, because there is no API separation, this was messy and required whitelisting circular header includes.

We need to make base a static library in a non-component build for code stripping purposes, and this change requires that the type of each of these subprojects be either a source set in a component build, or a static library in a static build. Not doing this conditional typing was the reason https://codereview.chromium.org/1528233002/ was reverted.

Because of these problems, it's better to just have base be a big target like it is in GYP. We can remove the weird whitelisting for the header checker, and not have to add conditional target types for every one for the static library issue.

This makes the debugging flags a public dep of base, and removes chrome/ui's dependency on it, just depending on base instead.

The output name of chrome_browser_ui was removed since the target is a source set and the name can collide.

TBR=dpranke@chromium.org

Committed: https://crrev.com/c44e20582891a9c7e587f4143c490d99ea3eac73
Cr-Commit-Position: refs/heads/master@{#366480}

[brettw, 2015-12-21 22:05:25]

Description was changed from

==========
Move base GN subprojects into base.

These were all subprojects to keep the build files closer to the source, as is
GN style.

However, because there is no API separation, this was messy and required
whitelisting circular header includes.

We need to make base a static library in a non-component build for code
stripping purposes, and this change requires that the type of each of these
subprojects be either a source set in a component build, or a static library in
a static build. Not doing this conditional typing was the reason
https://codereview.chromium.org/1528233002/ was reverted.

Because of these problems, it's better to just have base be a big target like it
is in GYP. We can remove the weird whitelisting for the header checker, and not
have to add conditional target types for every one for the static library issue.
==========

to

==========
Move base GN subprojects into base.

These were all subprojects to keep the build files closer to the source, as is
GN style.

However, because there is no API separation, this was messy and required
whitelisting circular header includes.

We need to make base a static library in a non-component build for code
stripping purposes, and this change requires that the type of each of these
subprojects be either a source set in a component build, or a static library in
a static build. Not doing this conditional typing was the reason
https://codereview.chromium.org/1528233002/ was reverted.

Because of these problems, it's better to just have base be a big target like it
is in GYP. We can remove the weird whitelisting for the header checker, and not
have to add conditional target types for every one for the static library issue.

This makes the debugging flags a public dep of base, and removes chrome/ui's
dependency on it, just depending on base instead.

The output name of chrome_browser_ui was removed since the target is a source
set and the name can collide.
==========

[brettw, 2015-12-21 22:05:25]

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

[brettw, 2015-12-21 22:05:29]

The CQ bit was checked by brettw@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-12-21 22:06:14]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1540953003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1540953003/1

[brettw, 2015-12-21 22:28:52]

Description was changed from

==========
Move base GN subprojects into base.

These were all subprojects to keep the build files closer to the source, as is
GN style.

However, because there is no API separation, this was messy and required
whitelisting circular header includes.

We need to make base a static library in a non-component build for code
stripping purposes, and this change requires that the type of each of these
subprojects be either a source set in a component build, or a static library in
a static build. Not doing this conditional typing was the reason
https://codereview.chromium.org/1528233002/ was reverted.

Because of these problems, it's better to just have base be a big target like it
is in GYP. We can remove the weird whitelisting for the header checker, and not
have to add conditional target types for every one for the static library issue.

This makes the debugging flags a public dep of base, and removes chrome/ui's
dependency on it, just depending on base instead.

The output name of chrome_browser_ui was removed since the target is a source
set and the name can collide.
==========

to

==========
Move base GN subprojects into base.

These were all subprojects to keep the build files closer to the source, as is
GN style.

However, because there is no API separation, this was messy and required
whitelisting circular header includes.

We need to make base a static library in a non-component build for code
stripping purposes, and this change requires that the type of each of these
subprojects be either a source set in a component build, or a static library in
a static build. Not doing this conditional typing was the reason
https://codereview.chromium.org/1528233002/ was reverted.

Because of these problems, it's better to just have base be a big target like it
is in GYP. We can remove the weird whitelisting for the header checker, and not
have to add conditional target types for every one for the static library issue.

This makes the debugging flags a public dep of base, and removes chrome/ui's
dependency on it, just depending on base instead.

The output name of chrome_browser_ui was removed since the target is a source
set and the name can collide.

TBR=dpranke@chromium.org
==========

[brettw, 2015-12-21 22:28:59]

The CQ bit was unchecked by brettw@chromium.org

[brettw, 2015-12-21 22:29:02]

The CQ bit was checked by brettw@chromium.org

[commit-bot: I haz the power, 2015-12-21 22:29:27]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1540953003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1540953003/1

[commit-bot: I haz the power, 2015-12-21 22:52:14]

Description was changed from

==========
Move base GN subprojects into base.

These were all subprojects to keep the build files closer to the source, as is
GN style.

However, because there is no API separation, this was messy and required
whitelisting circular header includes.

We need to make base a static library in a non-component build for code
stripping purposes, and this change requires that the type of each of these
subprojects be either a source set in a component build, or a static library in
a static build. Not doing this conditional typing was the reason
https://codereview.chromium.org/1528233002/ was reverted.

Because of these problems, it's better to just have base be a big target like it
is in GYP. We can remove the weird whitelisting for the header checker, and not
have to add conditional target types for every one for the static library issue.

This makes the debugging flags a public dep of base, and removes chrome/ui's
dependency on it, just depending on base instead.

The output name of chrome_browser_ui was removed since the target is a source
set and the name can collide.

TBR=dpranke@chromium.org
==========

to

==========
Move base GN subprojects into base.

These were all subprojects to keep the build files closer to the source, as is
GN style.

However, because there is no API separation, this was messy and required
whitelisting circular header includes.

We need to make base a static library in a non-component build for code
stripping purposes, and this change requires that the type of each of these
subprojects be either a source set in a component build, or a static library in
a static build. Not doing this conditional typing was the reason
https://codereview.chromium.org/1528233002/ was reverted.

Because of these problems, it's better to just have base be a big target like it
is in GYP. We can remove the weird whitelisting for the header checker, and not
have to add conditional target types for every one for the static library issue.

This makes the debugging flags a public dep of base, and removes chrome/ui's
dependency on it, just depending on base instead.

The output name of chrome_browser_ui was removed since the target is a source
set and the name can collide.

TBR=dpranke@chromium.org
==========

[commit-bot: I haz the power, 2015-12-21 22:52:16]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-12-21 22:53:15]

Description was changed from

==========
Move base GN subprojects into base.

These were all subprojects to keep the build files closer to the source, as is
GN style.

However, because there is no API separation, this was messy and required
whitelisting circular header includes.

We need to make base a static library in a non-component build for code
stripping purposes, and this change requires that the type of each of these
subprojects be either a source set in a component build, or a static library in
a static build. Not doing this conditional typing was the reason
https://codereview.chromium.org/1528233002/ was reverted.

Because of these problems, it's better to just have base be a big target like it
is in GYP. We can remove the weird whitelisting for the header checker, and not
have to add conditional target types for every one for the static library issue.

This makes the debugging flags a public dep of base, and removes chrome/ui's
dependency on it, just depending on base instead.

The output name of chrome_browser_ui was removed since the target is a source
set and the name can collide.

TBR=dpranke@chromium.org
==========

to

==========
Move base GN subprojects into base.

These were all subprojects to keep the build files closer to the source, as is
GN style.

However, because there is no API separation, this was messy and required
whitelisting circular header includes.

We need to make base a static library in a non-component build for code
stripping purposes, and this change requires that the type of each of these
subprojects be either a source set in a component build, or a static library in
a static build. Not doing this conditional typing was the reason
https://codereview.chromium.org/1528233002/ was reverted.

Because of these problems, it's better to just have base be a big target like it
is in GYP. We can remove the weird whitelisting for the header checker, and not
have to add conditional target types for every one for the static library issue.

This makes the debugging flags a public dep of base, and removes chrome/ui's
dependency on it, just depending on base instead.

The output name of chrome_browser_ui was removed since the target is a source
set and the name can collide.

TBR=dpranke@chromium.org

Committed: https://crrev.com/c44e20582891a9c7e587f4143c490d99ea3eac73
Cr-Commit-Position: refs/heads/master@{#366480}
==========

[commit-bot: I haz the power, 2015-12-21 22:53:16]

Patchset 1 (id:??) landed as
https://crrev.com/c44e20582891a9c7e587f4143c490d99ea3eac73
Cr-Commit-Position: refs/heads/master@{#366480}

[Nico, 2016-04-22 19:51:39]

thakis@chromium.org changed reviewers:
+ thakis@chromium.org

[Nico, 2016-04-22 19:51:40]

this means i have to do silly build.gn stamps like in
https://codereview.chromium.org/1900223003/ every now and then. any opposition
to having gni files with variables for sources or something like that, to
prevent that? in gyp, we have sub-gypi files that do this, and that works
reasonably well.

[brettw, 2016-04-22 20:45:57]

On 2016/04/22 19:51:40, Nico wrote:
> this means i have to do silly build.gn stamps like in
> https://codereview.chromium.org/1900223003/ every now and then. any opposition
> to having gni files with variables for sources or something like that, to
> prevent that? in gyp, we have sub-gypi files that do this, and that works
> reasonably well.

I prefer to avoid that since it's not a pattern we've used elsewhere and I think
people will find it confusing. But if the benefit is large then it seems
reasonable.

[Dirk Pranke, 2016-04-22 23:23:34]

On 2016/04/22 20:45:57, brettw wrote:
> On 2016/04/22 19:51:40, Nico wrote:
> > this means i have to do silly build.gn stamps like in
> > https://codereview.chromium.org/1900223003/ every now and then. any
opposition
> > to having gni files with variables for sources or something like that, to
> > prevent that? in gyp, we have sub-gypi files that do this, and that works
> > reasonably well.
> 
> I prefer to avoid that since it's not a pattern we've used elsewhere and I
think
> people will find it confusing. But if the benefit is large then it seems
> reasonable.

Unfortunately, I apparently was TBR'ed on this but see no indication that I
actually ever 
looked at it :(.

I agree that we should not go back to the world where we have lists of sources
in *.gni files.

Perhaps we should be trying to clean up the dependencies so that we don't have a
bunch
of circular includes instead?

I'm also confused by the source_set comment; if we have a static_library that
depends
on other source_sets, won't the source_sets get pulled in correctly
automatically like
they would for a shared library?

[brettw, 2016-04-24 23:20:01]

On 2016/04/22 23:23:34, Dirk Pranke wrote:
> On 2016/04/22 20:45:57, brettw wrote:
> > On 2016/04/22 19:51:40, Nico wrote:
> > > this means i have to do silly build.gn stamps like in
> > > https://codereview.chromium.org/1900223003/ every now and then. any
> opposition
> > > to having gni files with variables for sources or something like that, to
> > > prevent that? in gyp, we have sub-gypi files that do this, and that works
> > > reasonably well.
> > 
> > I prefer to avoid that since it's not a pattern we've used elsewhere and I
> think
> > people will find it confusing. But if the benefit is large then it seems
> > reasonable.
> 
> Unfortunately, I apparently was TBR'ed on this but see no indication that I
> actually ever 
> looked at it :(.
> 
> I agree that we should not go back to the world where we have lists of sources
> in *.gni files.
> 
> Perhaps we should be trying to clean up the dependencies so that we don't have
a
> bunch
> of circular includes instead?
> 
> I'm also confused by the source_set comment; if we have a static_library that
> depends
> on other source_sets, won't the source_sets get pulled in correctly
> automatically like
> they would for a shared library?

Children don't get linked into static libraries, they'll get linked as source
sets into the final target. The point of this is that these things need to be in
static libraries.

We added a "complete" static library which would cause the source sets to be
linked into the static library. But this isn't really semantically what complete
static libraries are for. Also, complete static libraries are relatively
untested.

[Dirk Pranke, 2016-04-24 23:35:08]

On 2016/04/24 23:20:01, brettw wrote:
> On 2016/04/22 23:23:34, Dirk Pranke wrote:
> > On 2016/04/22 20:45:57, brettw wrote:
> > > On 2016/04/22 19:51:40, Nico wrote:
> > > > this means i have to do silly build.gn stamps like in
> > > > https://codereview.chromium.org/1900223003/ every now and then. any
> > opposition
> > > > to having gni files with variables for sources or something like that,
to
> > > > prevent that? in gyp, we have sub-gypi files that do this, and that
works
> > > > reasonably well.
> > > 
> > > I prefer to avoid that since it's not a pattern we've used elsewhere and I
> > think
> > > people will find it confusing. But if the benefit is large then it seems
> > > reasonable.
> > 
> > Unfortunately, I apparently was TBR'ed on this but see no indication that I
> > actually ever 
> > looked at it :(.
> > 
> > I agree that we should not go back to the world where we have lists of
sources
> > in *.gni files.
> > 
> > Perhaps we should be trying to clean up the dependencies so that we don't
have
> a
> > bunch
> > of circular includes instead?
> > 
> > I'm also confused by the source_set comment; if we have a static_library
that
> > depends
> > on other source_sets, won't the source_sets get pulled in correctly
> > automatically like
> > they would for a shared library?
> 
> Children don't get linked into static libraries, they'll get linked as source
> sets into the final target. 

Ah, right.

> The point of this is that these things need to be in
> static libraries.
> 
> We added a "complete" static library which would cause the source sets to be
> linked into the static library. But this isn't really semantically what
complete
> static libraries are for. Also, complete static libraries are relatively
> untested.

I understand your point, but it would be interesting to see how different things
would really be in practice.

It looks like we don't actually use complete_static_lib=true anywhere in
chromium,
which makes it hard to infer actual needs. I wonder what would break if we 
changed things such that a complete static lib included all source_sets, but not

other dependent static libraries. E.g., for something like //base, what
non-//base/*
source_sets would get linked into the .a , and would we be upset by that?

[Dirk Pranke, 2016-04-24 23:36:33]

As an aside, 'complete_static_lib' doesn't show up as a flag in the help for
static_library ...