Use abstract configurations to switch between opt debug settings

Use abstract configurations to switch between opt debug settings

The problem is that conditions are evaluated before configuration inheritance is resolved, so we can't just define a configuration like this:

'Optdebug': {
  'inherits_from': ['Debug'],
  'variables': {
    'v8_optimized_debug': 2,
  }
}

Instead, we have to put the different settings depending on the optimization level into separate configurations, and use conditions inside the concrete configurations to inherit from the correct base class.

Common settings go in the base configuration DebugBaseCommon, and v8_optimized_debug dependent settings go into DebugBase{0,1,2}

The new Debug configuration inherits from DebugBaseCommon and DebugBase<(v8_optimized_debug), while the new configuration Optdebug inherits from DebugBaseCommon and DebugBase2.

BUG=v8:3252
R=machenbach@chromium.org, jkummerow@chromium.org
LOG=n

Committed: https://code.google.com/p/v8/source/detail?r=20605

[jochen (gone - plz use gerrit), 2014-04-03 22:21:37]

https://codereview.chromium.org/224443003/diff/40001/build/standalone.gypi
File build/standalone.gypi (right):

https://codereview.chromium.org/224443003/diff/40001/build/standalone.gypi#ne...
build/standalone.gypi:195: 'cflags': [ '-Wall', '<(werror)', '-W',
'-Wno-unused-parameter',
Any idea why these settings are used "twice" in the Optdebug configuration?

If you patch this into v8, and run ninja ia32.release, it'll create
out/ia32/{Release,Debug,Optdebug} and Debug and Optdebug only differ by the
settings in this section appearing twice, i.e.

cflags_cc is -Wnon-virtual-dtor -fno-rtti -Wnon-virtual-dtor -fno-rtti

[Nico, 2014-04-04 04:55:42]

I'm pretty surprised by the duplicate flags too. I wonder why that doesn't
happen for chromium. I'd add a few print statments in
build/gyp/pylib/gyp/input.py ('configuration'-related stuff, __init__.py and
generators/ninja.py ) :-/

https://codereview.chromium.org/224443003/diff/40001/build.ninja
File build.ninja (right):

https://codereview.chromium.org/224443003/diff/40001/build.ninja#newcode40
build.ninja:40: command = ninja -C out/$arch/$mode
So the way generator rules work is that they usually write build.ninja. Ninja
will then realize that build.ninja change and reload the manifest and redo its
thing. You shouldn't have to reexec ninja.

[tfarina, 2014-04-05 01:52:31]

This is a work in progress to replace the top-level Makefile, right?

https://codereview.chromium.org/224443003/diff/40001/build.ninja
File build.ninja (right):

https://codereview.chromium.org/224443003/diff/40001/build.ninja#newcode1
build.ninja:1: #Copyright 2014 the V8 project authors.All rights reserved.
nit-nit: space here between # and Copyright.

btw, could you tweak the similarity passed to git-cl upload to make rietveld
show this file as A rather than A+? This will make the diff of this file all
green, and not look like it was a copy of some other random file in the tree.

[jochen (gone - plz use gerrit), 2014-04-05 18:00:10]

On 2014/04/05 01:52:31, tfarina wrote:
> This is a work in progress to replace the top-level Makefile, right?

no, i'm trying to figure out what it takes to create an Optdebug configuration.
the ninja file just makes it easier to experiment with this.

[jochen (gone - plz use gerrit), 2014-04-05 18:17:21]

btw, the duplicatino happens somewhere inside SetUpConfigurations

[jochen (gone - plz use gerrit), 2014-04-08 20:34:21]

PTAL

[Michael Achenbach, 2014-04-09 08:48:55]

lgtm

[jochen (gone - plz use gerrit), 2014-04-09 09:55:02]

Committed patchset #5 manually as r20605 (presubmit successful).