Upstream Android-specific strings.

build/common.gypi

 # Copyright (c) 2012 The Chromium Authors. All rights reserved.
 # Use of this source code is governed by a BSD-style license that can be
 # found in the LICENSE file.
 
 # IMPORTANT:
 # Please don't directly include this file if you are building via gyp_chromium,
 # since gyp_chromium is automatically forcing its inclusion.
 {
   # Variables expected to be overriden on the GYP command line (-D) or by
   # ~/.gyp/include.gypi.
@@ skipping 418 matching lines @@
         # A flag to enable or disable our compile-time dependency
         # on gnome-keyring. If that dependency is disabled, no gnome-keyring
         # support will be available. This option is useful
         # for Linux distributions and for Aura.
         ['chromeos==1 or use_aura==1', {
           'use_gnome_keyring%': 0,
         }, {
           'use_gnome_keyring%': 1,
         }],
 
-        ['toolkit_views==0 or OS=="mac" or OS=="ios"', {
+        ['(toolkit_views==0 and OS!="android") or OS=="mac" or OS=="ios"', {

[sky, 2012/08/02 17:22:50]

Can you change the part you have in () to tookit_uses_gtk==1, eg:

'toolkit_uses_gtk==1 or OS=="mac" or OS=="ios"'

That matches the description on 440 and is easier to grok.

[newt (away), 2012/08/02 21:55:07]

Hmm... there doesn't seem to be an easy way to use toolkit_uses_gtk since it's
not actually defined in this scope.  If I try the suggestion above, I get an
error: 

NameError: name 'toolkit_uses_gtk' is not defined while evaluating condition
'toolkit_uses_gtk==1 or OS=="mac" or OS=="ios"'

The variable dependency chain is: grit_defines -> use_titlecase_in_grd_files ->
toolkit_uses_gtk -> use_aura, which requires more levels of nested 'variables'
sections than we have.

The easiest solution seems be to leaving the code as is, which appears to be
working so far.  Or maybe there's a gyp trick that could be used here?  Do you
have any suggestions?

[sky, 2012/08/03 16:48:52]

I'm surprised that this doesn't work since tookit_uses_gtk is defined above
this. Maybe Mark has some suggestions.

[Mark Mentovai, 2012/08/03 21:14:24]

toolkit_uses_gtk is defined in THIS variables block, inside a conditions block.
You can’t use variables defined in the same scope as yourself, you’d need to put
the definition in an inner variables scope. You can then re-export that inner
version back out. That looks like:

'variables': {
  'variables: {
    'conditions': [
      ['your_condition', {
        'toolkit_uses_gtk%': 1,
      }, {  # else
        'toolkit_uses_gtk%': 1,
      }],
    ],
  },
  'toolkit_uses_gtk': '<(toolkit_uses_gtk)',  # export this back out a level
  'conditions': [
    ['toolkit_uses_gtk==1', {  # now this works
    }],
  ],
}

Sorta like how the thing below that says “# Copy conditionally-set variables out
one scope.” works.

           # GTK+, Mac and iOS want Title Case strings
           'use_titlecase_in_grd_files%': 1,
         }],
 
         # Enable file manager extension on Chrome OS.
         ['chromeos==1', {
           'file_manager_extension%': 1,
         }, {
           'file_manager_extension%': 0,
         }],
@@ skipping 2883 matching lines @@
     # settings in target dicts.  SYMROOT is a special case, because many other
     # Xcode variables depend on it, including variables such as
     # PROJECT_DERIVED_FILE_DIR.  When a source group corresponding to something
     # like PROJECT_DERIVED_FILE_DIR is added to a project, in order for the
     # files to appear (when present) in the UI as actual files and not red
     # red "missing file" proxies, the correct path to PROJECT_DERIVED_FILE_DIR,
     # and therefore SYMROOT, needs to be set at the project level.
     'SYMROOT': '<(DEPTH)/xcodebuild',
   },
 }