Allow base to depend on allocator

Allow base to depend on allocator

A smaller, yet key, step to move

From: a situation where mainly executables (but not really) depend on
allocator, and base needs dependencies (to tcmalloc) to be injected
from content (which violates the ODR in component buids).

To: a situation where only base depends on allocator and the other
targets get recursively the required linked flags.

In essence this CL is a more gradual approach to the bigger
unreviewable crrev.com/1528013002.

How is the transition handled?
------------------------------
After this CL, the situation will be as follows:
From a build time perspective base will also depend on allocator.
This will not change anything substantial in static builds and introduce
yet another (temporary) ODR violation in Linux component builds.
The big change introduced by this CL is the fact that all the executable
targets that depend on base (virtualy all) will also get another
indirect dependency to allocator.

In other words, after this CL executable targets will depend on
allocator for two reasons:
 - Because they have an explicit dependency to it (the one I am going to
   get rid of in the immediate future).
 - Because this new transitive path I am introducing in base.

Rationale of this approach
--------------------------
This allows to restrict the critical changes in a smaller CL easier to
review, at the cost of the temporary double dependency on base.
The good things are:
 - If something will break, this CL will be very easy to revert.
 - The next cleanups will be straightforward.
 - We have now smoke tests (crrev.com/1577883002) that will help us
   realize if something goes wrong.

Next steps
----------
In the next CLs I will:
 - Remove the content -> base injection layer, and let base directly use
   the tcmalloc functions it needs.
 - Remove all the traces of USE_TCMALLOC outside of base.
 - Start cleaning up the hundreds use_allocator conditionals in the gyp
   files in a way which is easier to review and produce zero ninja diffs
   (see crrev.com/1583973002 as an example)

Ninja diffs caused by this change
---------------------------------
 ### Win, static build, GN:   https://paste.ee/p/hvcRp
 The missing targets (mostly tests) that previously were
 not depending on allocator, now get that by virtue of the transitive
 dependency.

 ### Win, static build, GYP:  https://paste.ee/p/AGuKR
 As above. Just GYP seems to emit the ninja files in a different,
 inlined, format.

 ### linux static build, GYP:  https://paste.ee/p/kmD7U
 As above. Plus the new targets also get the -Wl,-u (keep symbol)
 args as expected by allocator.gyp for the tcmalloc heap profiler.

 ### linux shared build, GYP: https://paste.ee/p/FHHNR
 Nothing relevant. Just I moved the dependency to allocator from
 base_unittests to base, and that is the only thing that reflects in the
 ninja files.

BUG=564618
Committed: https://crrev.com/58e5f8b23a68e6a87d89e87c6d9e6bef2c265ecd
Cr-Commit-Position: refs/heads/master@{#370405}

[Primiano Tucci (use gerrit), 2016-01-13 19:49:55]

Description was changed from

==========
Allow base to depend on allocator

Ninja diffs:
 Win, static build, GN:   https://paste.ee/p/hvcRp
 Win, static build, GYP:  https://paste.ee/p/AGuKR
 linux static build, GYP:  https://paste.ee/p/kmD7U
 linux shared build, GYP: https://paste.ee/p/FHHNR


BUG=564618
==========

to

==========
Allow base to depend on allocator

A smaller, yet key, step to move

From: a situation where mainly executables (but not really) depend on
allocator, and base needs dependencies (to tcmalloc) to be injected
from content (which violates the ODR in component buids).

To: a situation where only base depends on allocator and the other
targets get recursively the required linked flags.

In essence this CL is a more gradual approach to the bigger
unreviewable crrev.com/1528013002.

How is this transition handled? After this CL, the situation will be 
as follows:

From a build time perspective base will also depend on allocator.
This will not change anything substantial in static builds and introduce
yet another (temporary) ODR violation in Linux component builds.
The big change introduced by this CL is the fact that all the executable 
targets that depend on base (virtualy all) will also get another 
indirect dependency to allocator.

In other words, after this CL executable targets will depend on
allocator for two reasons:
 - Because they have an explicit dependency to it (the one I am going to
   get rid of in the immediate future).
 - Because this new transitive path I am introducing in base.

Rationale of this approach:
This allows to restrict the critical changes in a smaller CL easier to
review, at the cost of the temporary double dependency on base.
The good things are:
 - If something will break, this CL will be very easy to revert.
 - The next cleanups will be straightforward.
 - We have now smoke tests (crrev.com/1577883002) that will help us
   realize if something goes wrong.

In the next CLs I will:
 - Remove the content -> base injection layer, and let base directly use
   the tcmalloc functions it needs.
 - Remove all the traces of USE_TCMALLOC outside of base.
 - Start cleaning up the hundreds use_allocator conditionals in the gyp
   files in a way which is easier to review and produce zero ninja diffs
   (see crrev.com/1583973002) as an example

Ninja diffs caused by this change:
 Win, static build, GN:   https://paste.ee/p/hvcRp
 Win, static build, GYP:  https://paste.ee/p/AGuKR
 linux static build, GYP:  https://paste.ee/p/kmD7U
 linux shared build, GYP: https://paste.ee/p/FHHNR


BUG=564618
==========

[Primiano Tucci (use gerrit), 2016-01-13 19:58:50]

Description was changed from

==========
Allow base to depend on allocator

A smaller, yet key, step to move

From: a situation where mainly executables (but not really) depend on
allocator, and base needs dependencies (to tcmalloc) to be injected
from content (which violates the ODR in component buids).

To: a situation where only base depends on allocator and the other
targets get recursively the required linked flags.

In essence this CL is a more gradual approach to the bigger
unreviewable crrev.com/1528013002.

How is this transition handled? After this CL, the situation will be 
as follows:

From a build time perspective base will also depend on allocator.
This will not change anything substantial in static builds and introduce
yet another (temporary) ODR violation in Linux component builds.
The big change introduced by this CL is the fact that all the executable 
targets that depend on base (virtualy all) will also get another 
indirect dependency to allocator.

In other words, after this CL executable targets will depend on
allocator for two reasons:
 - Because they have an explicit dependency to it (the one I am going to
   get rid of in the immediate future).
 - Because this new transitive path I am introducing in base.

Rationale of this approach:
This allows to restrict the critical changes in a smaller CL easier to
review, at the cost of the temporary double dependency on base.
The good things are:
 - If something will break, this CL will be very easy to revert.
 - The next cleanups will be straightforward.
 - We have now smoke tests (crrev.com/1577883002) that will help us
   realize if something goes wrong.

In the next CLs I will:
 - Remove the content -> base injection layer, and let base directly use
   the tcmalloc functions it needs.
 - Remove all the traces of USE_TCMALLOC outside of base.
 - Start cleaning up the hundreds use_allocator conditionals in the gyp
   files in a way which is easier to review and produce zero ninja diffs
   (see crrev.com/1583973002) as an example

Ninja diffs caused by this change:
 Win, static build, GN:   https://paste.ee/p/hvcRp
 Win, static build, GYP:  https://paste.ee/p/AGuKR
 linux static build, GYP:  https://paste.ee/p/kmD7U
 linux shared build, GYP: https://paste.ee/p/FHHNR


BUG=564618
==========

to

==========
Allow base to depend on allocator

A smaller, yet key, step to move

From: a situation where mainly executables (but not really) depend on
allocator, and base needs dependencies (to tcmalloc) to be injected
from content (which violates the ODR in component buids).

To: a situation where only base depends on allocator and the other
targets get recursively the required linked flags.

In essence this CL is a more gradual approach to the bigger
unreviewable crrev.com/1528013002.

How is the transition handled?
------------------------------
After this CL, the situation will be as follows:
From a build time perspective base will also depend on allocator.
This will not change anything substantial in static builds and introduce
yet another (temporary) ODR violation in Linux component builds.
The big change introduced by this CL is the fact that all the executable 
targets that depend on base (virtualy all) will also get another 
indirect dependency to allocator.

In other words, after this CL executable targets will depend on
allocator for two reasons:
 - Because they have an explicit dependency to it (the one I am going to
   get rid of in the immediate future).
 - Because this new transitive path I am introducing in base.

Rationale of this approach
--------------------------
This allows to restrict the critical changes in a smaller CL easier to
review, at the cost of the temporary double dependency on base.
The good things are:
 - If something will break, this CL will be very easy to revert.
 - The next cleanups will be straightforward.
 - We have now smoke tests (crrev.com/1577883002) that will help us
   realize if something goes wrong.

Next steps
----------
In the next CLs I will:
 - Remove the content -> base injection layer, and let base directly use
   the tcmalloc functions it needs.
 - Remove all the traces of USE_TCMALLOC outside of base.
 - Start cleaning up the hundreds use_allocator conditionals in the gyp
   files in a way which is easier to review and produce zero ninja diffs
   (see crrev.com/1583973002) as an example

Ninja diffs caused by this change
---------------------------------
 ### Win, static build, GN:   https://paste.ee/p/hvcRp
 The missing targets (mostly tests) that previously were
 not depending on allocator, now get that by virtue of the transitive
 dependency.

 ### Win, static build, GYP:  https://paste.ee/p/AGuKR
 As above. Just GYP seems to emit the ninja files in a different, 
 inlined, format.
 
 ### linux static build, GYP:  https://paste.ee/p/kmD7U
 As above. Plus the new targets also get the -Wl,-u (keep symbol)
 args as expected by allocator.gyp for the tcmalloc heap profiler.
 
 ### linux shared build, GYP: https://paste.ee/p/FHHNR
 Nothing relevant. Just I moved the dependency to allocator from
 base_unittests to base, and that is the only thing that reflects in the
 ninja files.

BUG=564618
==========

[Primiano Tucci (use gerrit), 2016-01-13 20:02:37]

primiano@chromium.org changed reviewers:
+ thakis@chromium.org, wfh@chromium.org

[Primiano Tucci (use gerrit), 2016-01-13 20:02:37]

wfh/thakis another bit of patience.
If this flies, the remaining bits will be just boring and mechanical cleanups.

Essentially my new approach here is:
instead of doing everything atomically, which is what I tried in
crrev.com/1528013002, I'm gradually introducing first the base -> allocator dep,
and then doing the mechanical cleanups.

This is the core of the cleanup really at involves the most substantial build
changes.
The rest will be all --- lines from hundred gyp files.

Thanks for your patience

[Primiano Tucci (use gerrit), 2016-01-13 20:03:41]

Description was changed from

==========
Allow base to depend on allocator

A smaller, yet key, step to move

From: a situation where mainly executables (but not really) depend on
allocator, and base needs dependencies (to tcmalloc) to be injected
from content (which violates the ODR in component buids).

To: a situation where only base depends on allocator and the other
targets get recursively the required linked flags.

In essence this CL is a more gradual approach to the bigger
unreviewable crrev.com/1528013002.

How is the transition handled?
------------------------------
After this CL, the situation will be as follows:
From a build time perspective base will also depend on allocator.
This will not change anything substantial in static builds and introduce
yet another (temporary) ODR violation in Linux component builds.
The big change introduced by this CL is the fact that all the executable 
targets that depend on base (virtualy all) will also get another 
indirect dependency to allocator.

In other words, after this CL executable targets will depend on
allocator for two reasons:
 - Because they have an explicit dependency to it (the one I am going to
   get rid of in the immediate future).
 - Because this new transitive path I am introducing in base.

Rationale of this approach
--------------------------
This allows to restrict the critical changes in a smaller CL easier to
review, at the cost of the temporary double dependency on base.
The good things are:
 - If something will break, this CL will be very easy to revert.
 - The next cleanups will be straightforward.
 - We have now smoke tests (crrev.com/1577883002) that will help us
   realize if something goes wrong.

Next steps
----------
In the next CLs I will:
 - Remove the content -> base injection layer, and let base directly use
   the tcmalloc functions it needs.
 - Remove all the traces of USE_TCMALLOC outside of base.
 - Start cleaning up the hundreds use_allocator conditionals in the gyp
   files in a way which is easier to review and produce zero ninja diffs
   (see crrev.com/1583973002) as an example

Ninja diffs caused by this change
---------------------------------
 ### Win, static build, GN:   https://paste.ee/p/hvcRp
 The missing targets (mostly tests) that previously were
 not depending on allocator, now get that by virtue of the transitive
 dependency.

 ### Win, static build, GYP:  https://paste.ee/p/AGuKR
 As above. Just GYP seems to emit the ninja files in a different, 
 inlined, format.
 
 ### linux static build, GYP:  https://paste.ee/p/kmD7U
 As above. Plus the new targets also get the -Wl,-u (keep symbol)
 args as expected by allocator.gyp for the tcmalloc heap profiler.
 
 ### linux shared build, GYP: https://paste.ee/p/FHHNR
 Nothing relevant. Just I moved the dependency to allocator from
 base_unittests to base, and that is the only thing that reflects in the
 ninja files.

BUG=564618
==========

to

==========
Allow base to depend on allocator

A smaller, yet key, step to move

From: a situation where mainly executables (but not really) depend on
allocator, and base needs dependencies (to tcmalloc) to be injected
from content (which violates the ODR in component buids).

To: a situation where only base depends on allocator and the other
targets get recursively the required linked flags.

In essence this CL is a more gradual approach to the bigger
unreviewable crrev.com/1528013002.

How is the transition handled?
------------------------------
After this CL, the situation will be as follows:
From a build time perspective base will also depend on allocator.
This will not change anything substantial in static builds and introduce
yet another (temporary) ODR violation in Linux component builds.
The big change introduced by this CL is the fact that all the executable 
targets that depend on base (virtualy all) will also get another 
indirect dependency to allocator.

In other words, after this CL executable targets will depend on
allocator for two reasons:
 - Because they have an explicit dependency to it (the one I am going to
   get rid of in the immediate future).
 - Because this new transitive path I am introducing in base.

Rationale of this approach
--------------------------
This allows to restrict the critical changes in a smaller CL easier to
review, at the cost of the temporary double dependency on base.
The good things are:
 - If something will break, this CL will be very easy to revert.
 - The next cleanups will be straightforward.
 - We have now smoke tests (crrev.com/1577883002) that will help us
   realize if something goes wrong.

Next steps
----------
In the next CLs I will:
 - Remove the content -> base injection layer, and let base directly use
   the tcmalloc functions it needs.
 - Remove all the traces of USE_TCMALLOC outside of base.
 - Start cleaning up the hundreds use_allocator conditionals in the gyp
   files in a way which is easier to review and produce zero ninja diffs
   (see crrev.com/1583973002 as an example)

Ninja diffs caused by this change
---------------------------------
 ### Win, static build, GN:   https://paste.ee/p/hvcRp
 The missing targets (mostly tests) that previously were
 not depending on allocator, now get that by virtue of the transitive
 dependency.

 ### Win, static build, GYP:  https://paste.ee/p/AGuKR
 As above. Just GYP seems to emit the ninja files in a different, 
 inlined, format.
 
 ### linux static build, GYP:  https://paste.ee/p/kmD7U
 As above. Plus the new targets also get the -Wl,-u (keep symbol)
 args as expected by allocator.gyp for the tcmalloc heap profiler.
 
 ### linux shared build, GYP: https://paste.ee/p/FHHNR
 Nothing relevant. Just I moved the dependency to allocator from
 base_unittests to base, and that is the only thing that reflects in the
 ninja files.

BUG=564618
==========

[Will Harris, 2016-01-19 18:07:41]

On 2016/01/13 20:02:37, Primiano Tucci wrote:
> wfh/thakis another bit of patience.
> If this flies, the remaining bits will be just boring and mechanical cleanups.
> 
> Essentially my new approach here is:
> instead of doing everything atomically, which is what I tried in
> crrev.com/1528013002, I'm gradually introducing first the base -> allocator
dep,
> and then doing the mechanical cleanups.
> 
> This is the core of the cleanup really at involves the most substantial build
> changes.
> The rest will be all --- lines from hundred gyp files.
> 
> Thanks for your patience

as long as there is no issue with having double deps on allocator (which I don't
think there is) then lgtm

[Primiano Tucci (use gerrit), 2016-01-19 18:13:22]

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

[Primiano Tucci (use gerrit), 2016-01-19 18:13:22]

+brettw for the GN changes.

[brettw, 2016-01-19 20:20:33]

lgtm

https://codereview.chromium.org/1584893002/diff/1/base/BUILD.gn
File base/BUILD.gn (right):

https://codereview.chromium.org/1584893002/diff/1/base/BUILD.gn#newcode960
base/BUILD.gn:960: if (!is_nacl) {
I think the allocator should never be used in nacl, right? If that's the case, I
think it would be better to add this dep unconditionally and add the condition
to the allocator group (which already turns itself on and off in various
conditions).

[Primiano Tucci (use gerrit), 2016-01-20 14:08:01]

Patchset #2 (id:20001) has been deleted

[Primiano Tucci (use gerrit), 2016-01-20 14:11:43]

https://codereview.chromium.org/1584893002/diff/1/base/BUILD.gn
File base/BUILD.gn (right):

https://codereview.chromium.org/1584893002/diff/1/base/BUILD.gn#newcode960
base/BUILD.gn:960: if (!is_nacl) {
On 2016/01/19 20:20:33, brettw wrote:
> I think the allocator should never be used in nacl, right? 
Right.

>I think it would be better to add this dep unconditionally and add the
condition
> to the allocator group (which already turns itself on and off in various
> conditions).
Makes sense. IIUC you mean what I did here in PS3

[Nico, 2016-01-20 14:47:39]

lgtm

https://codereview.chromium.org/1584893002/diff/60001/base/base.gyp
File base/base.gyp (right):

https://codereview.chromium.org/1584893002/diff/60001/base/base.gyp#newcode24
base/base.gyp:24: 'allocator/allocator.gyp:allocator',
allocator is now on some platforms a source-less static_library we
unconditionally depend on. I think some generators used to have trouble with
that, but the ios bots (== xcode generator) are green, so I suppose it's fine
:-)

[Primiano Tucci (use gerrit), 2016-01-20 14:50:30]

https://codereview.chromium.org/1584893002/diff/60001/base/base.gyp
File base/base.gyp (right):

https://codereview.chromium.org/1584893002/diff/60001/base/base.gyp#newcode24
base/base.gyp:24: 'allocator/allocator.gyp:allocator',
On 2016/01/20 14:47:39, Nico wrote:
> allocator is now on some platforms a source-less static_library we
> unconditionally depend on. I think some generators used to have trouble with
> that, but the ios bots (== xcode generator) are green, so I suppose it's fine
> :-)

Yup. See the already existing TODO(primiano) in allocator.gyp:30
I'll fix that once all the crazyness is settled :)

[Primiano Tucci (use gerrit), 2016-01-20 14:50:38]

The CQ bit was checked by primiano@chromium.org

[Primiano Tucci (use gerrit), 2016-01-20 14:50:39]

The patchset sent to the CQ was uploaded after l-g-t-m from wfh@chromium.org,
brettw@chromium.org
Link to the patchset: https://codereview.chromium.org/1584893002/#ps60001
(title: "Move is_nacl condition to allocator group")

[commit-bot: I haz the power, 2016-01-20 14:50:57]

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

[commit-bot: I haz the power, 2016-01-20 15:58:39]

Description was changed from

==========
Allow base to depend on allocator

A smaller, yet key, step to move

From: a situation where mainly executables (but not really) depend on
allocator, and base needs dependencies (to tcmalloc) to be injected
from content (which violates the ODR in component buids).

To: a situation where only base depends on allocator and the other
targets get recursively the required linked flags.

In essence this CL is a more gradual approach to the bigger
unreviewable crrev.com/1528013002.

How is the transition handled?
------------------------------
After this CL, the situation will be as follows:
From a build time perspective base will also depend on allocator.
This will not change anything substantial in static builds and introduce
yet another (temporary) ODR violation in Linux component builds.
The big change introduced by this CL is the fact that all the executable 
targets that depend on base (virtualy all) will also get another 
indirect dependency to allocator.

In other words, after this CL executable targets will depend on
allocator for two reasons:
 - Because they have an explicit dependency to it (the one I am going to
   get rid of in the immediate future).
 - Because this new transitive path I am introducing in base.

Rationale of this approach
--------------------------
This allows to restrict the critical changes in a smaller CL easier to
review, at the cost of the temporary double dependency on base.
The good things are:
 - If something will break, this CL will be very easy to revert.
 - The next cleanups will be straightforward.
 - We have now smoke tests (crrev.com/1577883002) that will help us
   realize if something goes wrong.

Next steps
----------
In the next CLs I will:
 - Remove the content -> base injection layer, and let base directly use
   the tcmalloc functions it needs.
 - Remove all the traces of USE_TCMALLOC outside of base.
 - Start cleaning up the hundreds use_allocator conditionals in the gyp
   files in a way which is easier to review and produce zero ninja diffs
   (see crrev.com/1583973002 as an example)

Ninja diffs caused by this change
---------------------------------
 ### Win, static build, GN:   https://paste.ee/p/hvcRp
 The missing targets (mostly tests) that previously were
 not depending on allocator, now get that by virtue of the transitive
 dependency.

 ### Win, static build, GYP:  https://paste.ee/p/AGuKR
 As above. Just GYP seems to emit the ninja files in a different, 
 inlined, format.
 
 ### linux static build, GYP:  https://paste.ee/p/kmD7U
 As above. Plus the new targets also get the -Wl,-u (keep symbol)
 args as expected by allocator.gyp for the tcmalloc heap profiler.
 
 ### linux shared build, GYP: https://paste.ee/p/FHHNR
 Nothing relevant. Just I moved the dependency to allocator from
 base_unittests to base, and that is the only thing that reflects in the
 ninja files.

BUG=564618
==========

to

==========
Allow base to depend on allocator

A smaller, yet key, step to move

From: a situation where mainly executables (but not really) depend on
allocator, and base needs dependencies (to tcmalloc) to be injected
from content (which violates the ODR in component buids).

To: a situation where only base depends on allocator and the other
targets get recursively the required linked flags.

In essence this CL is a more gradual approach to the bigger
unreviewable crrev.com/1528013002.

How is the transition handled?
------------------------------
After this CL, the situation will be as follows:
From a build time perspective base will also depend on allocator.
This will not change anything substantial in static builds and introduce
yet another (temporary) ODR violation in Linux component builds.
The big change introduced by this CL is the fact that all the executable 
targets that depend on base (virtualy all) will also get another 
indirect dependency to allocator.

In other words, after this CL executable targets will depend on
allocator for two reasons:
 - Because they have an explicit dependency to it (the one I am going to
   get rid of in the immediate future).
 - Because this new transitive path I am introducing in base.

Rationale of this approach
--------------------------
This allows to restrict the critical changes in a smaller CL easier to
review, at the cost of the temporary double dependency on base.
The good things are:
 - If something will break, this CL will be very easy to revert.
 - The next cleanups will be straightforward.
 - We have now smoke tests (crrev.com/1577883002) that will help us
   realize if something goes wrong.

Next steps
----------
In the next CLs I will:
 - Remove the content -> base injection layer, and let base directly use
   the tcmalloc functions it needs.
 - Remove all the traces of USE_TCMALLOC outside of base.
 - Start cleaning up the hundreds use_allocator conditionals in the gyp
   files in a way which is easier to review and produce zero ninja diffs
   (see crrev.com/1583973002 as an example)

Ninja diffs caused by this change
---------------------------------
 ### Win, static build, GN:   https://paste.ee/p/hvcRp
 The missing targets (mostly tests) that previously were
 not depending on allocator, now get that by virtue of the transitive
 dependency.

 ### Win, static build, GYP:  https://paste.ee/p/AGuKR
 As above. Just GYP seems to emit the ninja files in a different, 
 inlined, format.
 
 ### linux static build, GYP:  https://paste.ee/p/kmD7U
 As above. Plus the new targets also get the -Wl,-u (keep symbol)
 args as expected by allocator.gyp for the tcmalloc heap profiler.
 
 ### linux shared build, GYP: https://paste.ee/p/FHHNR
 Nothing relevant. Just I moved the dependency to allocator from
 base_unittests to base, and that is the only thing that reflects in the
 ninja files.

BUG=564618
==========

[commit-bot: I haz the power, 2016-01-20 15:58:39]

Committed patchset #3 (id:60001)

[commit-bot: I haz the power, 2016-01-20 15:59:17]

Description was changed from

==========
Allow base to depend on allocator

A smaller, yet key, step to move

From: a situation where mainly executables (but not really) depend on
allocator, and base needs dependencies (to tcmalloc) to be injected
from content (which violates the ODR in component buids).

To: a situation where only base depends on allocator and the other
targets get recursively the required linked flags.

In essence this CL is a more gradual approach to the bigger
unreviewable crrev.com/1528013002.

How is the transition handled?
------------------------------
After this CL, the situation will be as follows:
From a build time perspective base will also depend on allocator.
This will not change anything substantial in static builds and introduce
yet another (temporary) ODR violation in Linux component builds.
The big change introduced by this CL is the fact that all the executable 
targets that depend on base (virtualy all) will also get another 
indirect dependency to allocator.

In other words, after this CL executable targets will depend on
allocator for two reasons:
 - Because they have an explicit dependency to it (the one I am going to
   get rid of in the immediate future).
 - Because this new transitive path I am introducing in base.

Rationale of this approach
--------------------------
This allows to restrict the critical changes in a smaller CL easier to
review, at the cost of the temporary double dependency on base.
The good things are:
 - If something will break, this CL will be very easy to revert.
 - The next cleanups will be straightforward.
 - We have now smoke tests (crrev.com/1577883002) that will help us
   realize if something goes wrong.

Next steps
----------
In the next CLs I will:
 - Remove the content -> base injection layer, and let base directly use
   the tcmalloc functions it needs.
 - Remove all the traces of USE_TCMALLOC outside of base.
 - Start cleaning up the hundreds use_allocator conditionals in the gyp
   files in a way which is easier to review and produce zero ninja diffs
   (see crrev.com/1583973002 as an example)

Ninja diffs caused by this change
---------------------------------
 ### Win, static build, GN:   https://paste.ee/p/hvcRp
 The missing targets (mostly tests) that previously were
 not depending on allocator, now get that by virtue of the transitive
 dependency.

 ### Win, static build, GYP:  https://paste.ee/p/AGuKR
 As above. Just GYP seems to emit the ninja files in a different, 
 inlined, format.
 
 ### linux static build, GYP:  https://paste.ee/p/kmD7U
 As above. Plus the new targets also get the -Wl,-u (keep symbol)
 args as expected by allocator.gyp for the tcmalloc heap profiler.
 
 ### linux shared build, GYP: https://paste.ee/p/FHHNR
 Nothing relevant. Just I moved the dependency to allocator from
 base_unittests to base, and that is the only thing that reflects in the
 ninja files.

BUG=564618
==========

to

==========
Allow base to depend on allocator

A smaller, yet key, step to move

From: a situation where mainly executables (but not really) depend on
allocator, and base needs dependencies (to tcmalloc) to be injected
from content (which violates the ODR in component buids).

To: a situation where only base depends on allocator and the other
targets get recursively the required linked flags.

In essence this CL is a more gradual approach to the bigger
unreviewable crrev.com/1528013002.

How is the transition handled?
------------------------------
After this CL, the situation will be as follows:
From a build time perspective base will also depend on allocator.
This will not change anything substantial in static builds and introduce
yet another (temporary) ODR violation in Linux component builds.
The big change introduced by this CL is the fact that all the executable
targets that depend on base (virtualy all) will also get another
indirect dependency to allocator.

In other words, after this CL executable targets will depend on
allocator for two reasons:
 - Because they have an explicit dependency to it (the one I am going to
   get rid of in the immediate future).
 - Because this new transitive path I am introducing in base.

Rationale of this approach
--------------------------
This allows to restrict the critical changes in a smaller CL easier to
review, at the cost of the temporary double dependency on base.
The good things are:
 - If something will break, this CL will be very easy to revert.
 - The next cleanups will be straightforward.
 - We have now smoke tests (crrev.com/1577883002) that will help us
   realize if something goes wrong.

Next steps
----------
In the next CLs I will:
 - Remove the content -> base injection layer, and let base directly use
   the tcmalloc functions it needs.
 - Remove all the traces of USE_TCMALLOC outside of base.
 - Start cleaning up the hundreds use_allocator conditionals in the gyp
   files in a way which is easier to review and produce zero ninja diffs
   (see crrev.com/1583973002 as an example)

Ninja diffs caused by this change
---------------------------------
 ### Win, static build, GN:   https://paste.ee/p/hvcRp
 The missing targets (mostly tests) that previously were
 not depending on allocator, now get that by virtue of the transitive
 dependency.

 ### Win, static build, GYP:  https://paste.ee/p/AGuKR
 As above. Just GYP seems to emit the ninja files in a different,
 inlined, format.

 ### linux static build, GYP:  https://paste.ee/p/kmD7U
 As above. Plus the new targets also get the -Wl,-u (keep symbol)
 args as expected by allocator.gyp for the tcmalloc heap profiler.

 ### linux shared build, GYP: https://paste.ee/p/FHHNR
 Nothing relevant. Just I moved the dependency to allocator from
 base_unittests to base, and that is the only thing that reflects in the
 ninja files.

BUG=564618

Committed: https://crrev.com/58e5f8b23a68e6a87d89e87c6d9e6bef2c265ecd
Cr-Commit-Position: refs/heads/master@{#370405}
==========

[commit-bot: I haz the power, 2016-01-20 15:59:18]

Patchset 3 (id:??) landed as
https://crrev.com/58e5f8b23a68e6a87d89e87c6d9e6bef2c265ecd
Cr-Commit-Position: refs/heads/master@{#370405}

[robert.bradford, 2016-01-20 16:31:44]

A revert of this CL (patchset #3 id:60001) has been created in
https://codereview.chromium.org/1610673002/ by robert.bradford@intel.com.

The reason for reverting is: Made the tree go red - build failure on iOS_Device:
https://build.chromium.org/p/chromium.mac/builders/iOS_Device/builds/35574.

[Primiano Tucci (use gerrit), 2016-01-20 16:33:43]

That was quick!

Nico: I guess that the reason of the failure

>clang: error: no such file or directory:
'/b/build/slave/iOS_Device/build/src/xcodebuild/Release-iphoneos/liballocator.a'

Is precisely what you predicted right?
I guess I'll have to deal with that TODO sonner than expected.

[Primiano Tucci (use gerrit), 2016-01-20 18:16:42]

For the records, this is relanding in :

https://codereview.chromium.org/1605023004