Convert the existing .gyp configuration to use the new base\allocator...

Convert the existing .gyp configuration to use the new base\allocator
library with upstream source code from the new vendor branch patterns
in third_party\jemalloc and third_party\tcmalloc.
BUG=27911
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=33208

[sgk, 2009-11-25 04:15:00]

The previous CLs branched the necessary files for the new layout so both old and
new are side-by-side.  This CL pulls the trigger.

After this lands and we're confident any problems have been shaken out, a
follow-on CL will delete the forked files from their old locations in
third_party\tcmalloc and remove the tcmalloc entry from DEPS.

[jar (doing other things), 2009-11-25 17:12:20]

I'm not in any way a gyp expert... so all I did was sanity check this... and it
seemed to make sense.

LGTM with some alphabetizing nits below.  There are probably a few other
mis-orderings in the file that uses the "<" syntax, but it was not clear what
the "standard" ordering should be.

It would be good to wait at least a few days after landing before doing the
"cleanup" CL, as I have some delta's in the old area that I need to migrate.

http://codereview.chromium.org/435040/diff/2001/2002
File build/all.gyp (right):

http://codereview.chromium.org/435040/diff/2001/2002#newcode95
build/all.gyp:95: '../base/allocator/allocator.gyp:*',
Should this be better alphabetized? ... or is there an ordering issue?

http://codereview.chromium.org/435040/diff/2001/2004
File chrome/chrome.gyp (right):

http://codereview.chromium.org/435040/diff/2001/2004#newcode2758
chrome/chrome.gyp:2758: '<(allocator_target)',
nit: Here the ordering is "." then "<" then "i" (a letter).  Down below, it is
the exact opposite.  Is the ordering critical, or should this be alphabetized?

http://codereview.chromium.org/435040/diff/2001/2004#newcode4371
chrome/chrome.gyp:4371: '<(allocator_target)',
nit: Here ordering is "t" (a letter), ".", "<".  See conflicting ordering above.

http://codereview.chromium.org/435040/diff/2001/2004#newcode4941
chrome/chrome.gyp:4941: '../views/views.gyp:views',
nit: again odd ordering.

http://codereview.chromium.org/435040/diff/2001/2004#newcode6550
chrome/chrome.gyp:6550: '../base/allocator/allocator.gyp:*',
nit: reorder up one line.

[sgk, 2009-11-25 17:19:46]

http://codereview.chromium.org/435040/diff/2001/2002
File build/all.gyp (right):

http://codereview.chromium.org/435040/diff/2001/2002#newcode95
build/all.gyp:95: '../base/allocator/allocator.gyp:*',
On 2009/11/25 17:12:20, jar wrote:
> Should this be better alphabetized? ... or is there an ordering issue?

Done.

http://codereview.chromium.org/435040/diff/2001/2004
File chrome/chrome.gyp (right):

http://codereview.chromium.org/435040/diff/2001/2004#newcode2758
chrome/chrome.gyp:2758: '<(allocator_target)',
On 2009/11/25 17:12:20, jar wrote:
> nit: Here the ordering is "." then "<" then "i" (a letter).  Down below, it is
> the exact opposite.  Is the ordering critical, or should this be alphabetized?

This is the first time we've used a variable to parameterize a dependent target
like this, so there's no set order yet.  (I wanted to do this so we could switch
back, if necessary, with a one-liner in the variable definition.)  I've changed
all of these to put the variable at the end of each list, which is arbitrary but
at least consistent.

http://codereview.chromium.org/435040/diff/2001/2004#newcode6550
chrome/chrome.gyp:6550: '../base/allocator/allocator.gyp:*',
On 2009/11/25 17:12:20, jar wrote:
> nit: reorder up one line.

Done.

[sgk, 2009-11-26 14:49:49]

TBR=jar

Overnight trybot and other test runs passed, so I'm pulling the trigger on this.
 I'll send out chromium-dev mail to explain the change.