Add support of x64 to generate .mk files

build/gyp_chromium

Index: build/gyp_chromium
diff --git a/build/gyp_chromium b/build/gyp_chromium
index b06552db32ba7b7e4ac56073487ad9493a8e5161..66ef75d16466b5ea00f77ffbb3739a45065df4b0 100755
--- a/build/gyp_chromium
+++ b/build/gyp_chromium
@@ -550,12 +550,14 @@ if __name__ == '__main__':
           'GYP_CROSSCOMPILE' not in os.environ)):
     os.environ['GYP_CROSSCOMPILE'] = '1'
 
-  if not RunGN(gn_vars_dict):
-    sys.exit(1)
+  if not 'android_webview_build=1' in os.environ.get('GYP_DEFINES', []):
+    if not RunGN(gn_vars_dict):
+      sys.exit(1)
+

[Yang Gu, 2014/03/13 10:07:29]

We don't need to run gn and landmines.py (below) for webview makefiles, right?
This will dumb the complaint in build/toolchain/android/BUILD.gn and
build/config/android/config.gni.

[Torne, 2014/03/13 11:04:46]

No, we can't just skip running gn for the webview build. It happens that right
now running gn doesn't do anything anyway (even for the non-webview build) so
skipping it doesn't hurt, but webview has no special exemption here, and will
require gn if the regular chrome build does.

However, we're intending to remove gn here entirely (for the time being) since
the project wasn't making progress; it may be revisited at some point in the
future. You could just wait for that to happen :)
In the long term when the gn project gets back on track, you will have to add
all the required definitions to the gn configuration to work with x86_64 as well
as doing it in gyp.

[Yang Gu, 2014/03/13 16:06:07]

gn is quite a new thing to me and thanks a lot for the valuable info. Actually
today I tried to fix the error reported in gn, and one of them is as below:
gcc_toolchain("x64") {
  prefix =
"$android_ndk_root/toolchains/x86_64-4.8/prebuilt/$build_os-$android_host_arch/bin/x86_64-linux-android-"
  cc  = prefix + "gcc"
  cxx = prefix + "g++"
  ar  = prefix + "ar"
  ld  = cxx

  toolchain_cpu_arch = "x64"
  toolchain_os = "android"
}

I know this piece of code is useful for ndk build, but it's not related to this
CL to generate makefiles using AOSP build system (assuming we don't have ndk
now).
If you feel it's better to fix in gn related code, I'd like to submit the patch.
Actually we already have this patch at hand, and we can build x64
libwebviewchromium.so with local ndk. 

In all, I feel the logic of current scripts is not very clear to support both
AOSP and ndk build systems. Hope I can be more help here:)

[Torne, 2014/03/17 15:28:14]

No, what I suggested is that you wait until after gn has been removed from the
chromium build, as then this won't matter at all.

   args.extend(
       ['-I' + i for i in additional_include_files(supplemental_includes, args)])
 
-  args.extend(['-D', 'gyp_output_dir=' + GetOutputDirectory()])
+  args.extend(['-Dgyp_output_dir=' + GetOutputDirectory()])

[Yang Gu, 2014/03/13 10:07:29]

This is to unify the format of parameter to be -Dxxx, instead of two parameters.

 
   print 'Updating projects from gyp files...'
   sys.stdout.flush()
@@ -566,9 +568,10 @@ if __name__ == '__main__':
   # Check for landmines (reasons to clobber the build). This must be run here,
   # rather than a separate runhooks step so that any environment modifications
   # from above are picked up.
-  print 'Running build/landmines.py...'
-  subprocess.check_call(
-      [sys.executable, os.path.join(script_dir, 'landmines.py')])
+  if not 'android_webview_build=1' in os.environ.get('GYP_DEFINES', []):

[Torne, 2014/03/13 11:04:46]

Why do you need to disable running landmines? We've not had to do this on other
architectures, it doesn't seem to hurt even though it's not doing anything
useful.

[Yang Gu, 2014/03/13 16:06:07]

yes, this part doesn't hurt (except speed:)), and I don't need extra change to
add this part back.

[Torne, 2014/03/17 15:28:14]

I'm not sure what you mean here. If there's no need to change this, then don't
change it.

+    print 'Running build/landmines.py...'
+    subprocess.check_call(
+        [sys.executable, os.path.join(script_dir, 'landmines.py')])
 
   if vs2013_runtime_dll_dirs:
     x64_runtime, x86_runtime = vs2013_runtime_dll_dirs