Android: Add chrome-specific dynamic linker.

base/base.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.
 
 {
   'target_defaults': {
     'variables': {
       'base_target': 0,
     },
     'target_conditions': [
@@ skipping 764 matching lines @@
               ['include', '^threading/platform_thread_linux\\.cc$'],
             ],
           }],
           ['OS == "android" and <(android_webview_build)==1', {
             'defines': [
                # WebView builds as part of the system which already has sincos;
                # avoid defining it again as it causes a linker warning.
                'ANDROID_SINCOS_PROVIDED',
             ],
           }],
+          ['OS == "android"', {
+            'includes': [
+              # Pull compiler flags related to low-memory device detection.
+              '../build/android/low_memory_device.gypi',
+            ],
+          }],

[Nico, 2013/10/10 16:51:10]

I'm not sure we want a dependency from base on build. I didn't follow the review
too closely, maybe you added this because someone complained about the
include-only-don't-depend-on-base .h file you had previously.

Maybe this gypi file could just live in base/android ? Or can't the target that
must not depend on base include a gypi file from base/android either?

[digit1, 2013/10/11 08:00:12]

Yes, that's exactly what happened. For the record, we already have
build/android/cpufeatures.gypi which is used by base/, content/, skia/ and
third_party/libwebp/. This makes sense because it is used to define a common
module that cannot be in base/

I think this use case is very similar, and I don't see the point of putting the
file under base/android/ given that another module which cannot depend on base/
will need to include it.
Yes, the other target that includes this gypi must _not_ depend on base, and
even has a DEPS file that checks for this. Hence the need for a common location,
outside of base/.

The alternative is to define something in common.gypi, but I find this less
elegant because it would become visible to all targets.

I can't help feeling that maybe we're over-doing this, the only reason for this
is to share the value of a single constant (512) which is very, very, unlikely
to change in the future :-)

[jar (doing other things), 2013/10/14 19:36:45]

I think that usually such "sharing dependencies" are accomplished by calling
into base to force the setting (somewhere during startup?), rather than by
inclusion (by base) during compilation of external (non-base) code.

Is that workable?

[digit1, 2013/10/14 20:01:08]

The main issue is that this injection needs to happen before any use of the
corresponding value, which is difficult to guarantee due to the complicated
initialization code paths on Android (yes, I'm writing code pathS, because the
way initialization works varies heavily depending on which Chromium-based APK is
being built). I really think this is going to add a lot of complexity for very
little benefits.

Again, I'm thinking we're overdoing this, I'm really tempted to hard-coding the
value in each respective component given it's so unlikely to change anyway.

           ['OS == "ios" and _toolset != "host"', {
             'sources/': [
               # Pull in specific Mac files for iOS (which have been filtered out
               # by file name rules).
               ['include', '^atomicops_internals_mac\\.'],
               ['include', '^base_paths_mac\\.'],
               ['include', '^file_util_mac\\.'],
               ['include', '^file_version_info_mac\\.'],
               ['include', '^mac/bundle_locations\\.'],
               ['include', '^mac/foundation_util\\.'],
@@ skipping 120 matching lines @@
           ['<(toolkit_uses_gtk) == 1', {
             'sources!': [
               'x11/x11_error_tracker.cc',
             ],
           }],
         ],
       }],
     ],
   },
 }