Set USE(NEW_THEME) in config.h instead of a gyp file

USE(NEW_THEME) variable does not need to be exposed to the gyp build system.
    
BUG=286578
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=157759

[lgombos, 2013-08-10 22:04:06]

Fix a FIXME and reduce the scope of the macro from global to only where it is
needed.

[abarth-chromium, 2013-08-12 19:43:21]

https://codereview.chromium.org/22577011/diff/1/Source/core/rendering/RenderT...
File Source/core/rendering/RenderTheme.h (right):

https://codereview.chromium.org/22577011/diff/1/Source/core/rendering/RenderT...
Source/core/rendering/RenderTheme.h:28: #endif
This should got in Platform.h rather than here.  We assume that USE macros a
visible globally in the project.

[lgombos, 2013-08-13 14:52:45]

https://codereview.chromium.org/22577011/diff/1/Source/core/rendering/RenderT...
File Source/core/rendering/RenderTheme.h (right):

https://codereview.chromium.org/22577011/diff/1/Source/core/rendering/RenderT...
Source/core/rendering/RenderTheme.h:28: #endif
On 2013/08/12 19:43:21, abarth wrote:
> This should got in Platform.h rather than here.  We assume that USE macros a
> visible globally in the project.

It seems to me that from the ~20 USE() guards currently in Blink, most of the
guards are only used under core/ (layers on top of wtf/) and many are already
set/scoped so that they are not visible under wtf/ (WEBAUDIO_XX,
NATIVE_FULLSCREEN_VIDEO, CONCATENATED_IMPULSE_RESPONSES, etc.).

The only macro I've found that is used both under wtf/ and core/ is USE(CF), the
rest seems to be only used either under wtf/ or layers above wtf/.

We also seem to be inconsistent abut whether these macros are set in .h files or
in .gyp* files. Many are set in core/features.gypi and many in Platform.h. My
understanding was that we should aim to eliminate Platform.h in the hope of
gaining on build times.
  
I see value in scoping these macros to be either just for wtf/ or for layers
above wtf (and perhaps revisit the one/few macros that are used in both layers).

Thoughts ?

[abarth-chromium, 2013-08-13 20:22:08]

On 2013/08/13 14:52:45, lgombos wrote:
> We also seem to be inconsistent abut whether these macros are set in .h files
or
> in .gyp* files.

WTF_USE_* should be set in h files.  ENABLE_* should be set in features.gypi.

> Many are set in core/features.gypi and many in Platform.h. My
> understanding was that we should aim to eliminate Platform.h in the hope of
> gaining on build times.

Have you validated that eliminating Platform.h improves build times?  If so, by
how much on which platforms?

> I see value in scoping these macros to be either just for wtf/ or for layers
> above wtf (and perhaps revisit the one/few macros that are used in both
layers).

The counter-argument is that currently developers assume that USE(*) macros have
the same value in every Blink compilation unit.  If we wanted to scope them more
tightly, we'd have to change the name of the macro to make its scope clearer.

[lgombos, 2013-08-20 22:27:28]

On 2013/08/13 20:22:08, abarth wrote:
> On 2013/08/13 14:52:45, lgombos wrote:
> > We also seem to be inconsistent abut whether these macros are set in .h
files or in .gyp* files.

I'd like to turn this bug to trying to set WTF_USE macros consistently.

> WTF_USE_* should be set in h files.  ENABLE_* should be set in features.gypi.

Adam, can you tell more about why you recommend a different policy for WTF_USE_*
(.h files) than the ENABLE_* (.gyp) macros ?

It seems that the current features.gypi and core.gyp needs some of the WTF_USE_*
macros exposed to be visible in the build system as well, and not just in h/cxx
files.

[abarth-chromium, 2013-08-21 16:59:54]

On 2013/08/20 22:27:28, lgombos wrote:
> Adam, can you tell more about why you recommend a different policy for
WTF_USE_*
> (.h files) than the ENABLE_* (.gyp) macros ?

Like like to eventually remove all the ENABLE_* macros in favor of runtime
flags.  We'll still have WTF_USE_* macros indefinitely, but they should not be
configurable via the build system.

> It seems that the current features.gypi and core.gyp needs some of the
WTF_USE_*
> macros exposed to be visible in the build system as well, and not just in
h/cxx
> files.

In features.gypi, I see WTF_USE_NATIVE_FULLSCREEN_VIDEO,
WTF_USE_WEBAUDIO_FFMPEG, and WTF_USE_HARFBUZZ.  Those can and should be defined
in Platform.h, not in features.gypi because they are consequences of the current
platform.

The use of WTF_USE_* in core.gyp is just wrong and should be deleted.  We should
set those compiler flags based on the current platform, not based on whether a
USE macro is in feature_defines.

[lgombos, 2013-09-07 03:25:55]

Set USE(NEW_THEME) in config.h instead of a gyp file.

[abarth-chromium, 2013-09-07 20:45:14]

LGTM

Do we still need this ifdef?  Is there an old theme somewhere?

[lgombos, 2013-09-07 21:59:10]

On 2013/09/07 20:45:14, abarth wrote:
> LGTM
> 
> Do we still need this ifdef?  Is there an old theme somewhere?

USE() macros are sometimes used for readability as there is a one-to-one mapping
between an OS() macros and a USE() macro. This seems to be the case here.
USE(MAC_THEME) would be a better name or just replace it with OS(MACOSX).

[commit-bot: I haz the power, 2013-09-13 12:47:01]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/l.gombos@samsung.com/22577011/17001

[commit-bot: I haz the power, 2013-09-13 14:56:40]

Retried try job too often on win_blink_rel for step(s) webkit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_blink_...

[commit-bot: I haz the power, 2013-09-13 15:47:41]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/l.gombos@samsung.com/22577011/17001

[commit-bot: I haz the power, 2013-09-13 16:29:01]

Change committed as 157759