Client-based geolocation support.

chrome/chrome_browser.gypi

Index: chrome/chrome_browser.gypi
diff --git a/chrome/chrome_browser.gypi b/chrome/chrome_browser.gypi
index cc6775f511bb65ec3a97a88dca1a526278789059..4553042b5a0de9db1056c39caefc32e13bdb43e4 100644
--- a/chrome/chrome_browser.gypi
+++ b/chrome/chrome_browser.gypi
@@ -4274,6 +4274,9 @@
             'browser/importer/nss_decryptor_system_nss.h',
           ],
         }],
+        ['"ENABLE_CLIENT_BASED_GEOLOCATION=1" in feature_defines', {

[joth, 2010/12/07 10:24:51]

this looks unusual, not least because it is = rather than == like the other
conditions.
Maybe put a comment on this saying it's an transitory thing whilst bug X is in
progress and it will be removed real soon.

The other option is to unconditionally set the ENABLE_CLIENT_BASED_GEOLOCATION
define here, and have a comment saying it should be kept in sync with the value
in feature defines.

[John Knottenbelt, 2010/12/07 12:30:04]

I'll add a comment in to say that it will disappear once we have completed a
migration to client-based geolocation (together with some bug references).

The defines in feature_override.gypi are only automatically exposed as
preprocessor macros when compiling the WebKit source. The above exposes
ENABLE_CLIENT_BASED_GEOLOCATION as a preprocessor macro when compiling Chromium
code.

+          'defines': [ 'ENABLE_CLIENT_BASED_GEOLOCATION=1' ]

[joth, 2010/12/07 10:24:51]

ah, I see that explains it, this is a different ENABLE_CLIENT_BASED_GEOLOCATION
macro to the feature_defines one.
As they carry different values ([0,1] vs [undefined,1]) maybe give them
different names?

[John Knottenbelt, 2010/12/07 12:30:04]

The feature_defines array is purely a gyp variable. In WebKit, these are exposed
as ENABLE_XXX if ENABLE_XXX=1 is present in the features_defines and undefined
otherwise, which is why I have adopted the same practice on this end.

+        }],
       ],
     },
     {