Scripts to generate Android.mk for framework Skia.

gyp/common_conditions.gypi

Index: gyp/common_conditions.gypi
diff --git a/gyp/common_conditions.gypi b/gyp/common_conditions.gypi
index f3caddccfedc77b5fc83fd44d4f158ba7710a507..26788e0b6ee4f07131d3d3b7cfa0884d7972b778 100644
--- a/gyp/common_conditions.gypi
+++ b/gyp/common_conditions.gypi
@@ -193,6 +193,60 @@
       },
     ],
 
+    ['skia_android_framework', {
+      'cflags': [
+        # Skia does not enforce this usage pattern so we disable it here to avoid
+        # unecessary log spew when building
+        '-Wno-unused-parameter',
+
+        # Android's -D_FORTIFY_SOURCE=2 extensions are incompatibile with SkString.
+        # Revert to -D_FORTIFY_SOURCE=1
+        '-U_FORTIFY_SOURCE',
+        '-D_FORTIFY_SOURCE=1',
+      ],
+      'cflags!': [

[djsollen, 2014/01/21 17:47:37]

how do we determine what goes in this list?

[scroggo, 2014/01/21 19:10:06]

Mostly these are flags that ended up in the final generated Android.mk (i.e. our
conditions resulted in them being set*) which weren't there in the hand edited
one.

The reason I removed them ALL was because with all of them set I was able to
build but the final result failed to boot on my Android device. Instead of
figuring out one by one which were okay, I used my cheat sheet (the hand edited
Android.mk).

Should some of these flags be set (or are some indifferent)?

* Another way of doing this would be to prevent each of these flags from being
set if skia_android_framework == 1. I started off using that method, but
switched to turning them off here because I wasn't sure which ones HAD to be
turned off.

+        '-fstrict-aliasing',
+        '-Wall',
+        '-Wno-c++11-extensions',
+        '-fuse-ld=gold',
+        '-fno-exceptions',
+        '-fomit-frame-pointer',
+        '-mno-apcs-frame',
+        '-g',

[scroggo, 2014/01/21 19:10:06]

This flag came along with using the default configuration, which was SK_DEBUG. I
think the way the current Android.mk is written makes sense: -g is NOT defined,
and if someone wants to debug they can define it (maybe it would be better to
use a release build?).

This may bring up a larger issue: as far as I can tell, our gyp files currently
do not compile different files (only sections of code within files are
selected/deselected). This works with the current model where someone compiling
Android can modify the makefile slightly in order to get the desired
debug/release/developer build (this also means it makes little difference which
build flavor I request from gyp). If we were to make a change to Skia that
requires different files for different build flavors, it would require some more
complexity for generating Android.mk

+        '-mthumb',
+        '-march=armv7-a',
+        '-mfpu=neon',
+        '-mfloat-abi=softfp',
+        '-msse2',
+        '-mssse3',
+      ],
+      'cflags_cc!': [
+        '-fno-rtti',
+      ],
+      'defines': [
+        'DCT_IFAST_SUPPORTED',
+        # using freetype's embolden allows us to adjust fake bold settings at
+        # draw-time, at which point we know which SkTypeface is being drawn
+        'SK_USE_FREETYPE_EMBOLDEN',
+        # Android provides at least FreeType 2.4.0 at runtime.
+        'SK_FONTHOST_FREETYPE_RUNTIME_VERSION=0x020400',
+        # Skia should not use dlopen on Android.
+        'SK_CAN_USE_DLOPEN=0',
+      ],
+      'defines!': [
+        # Don't hardcode these into the Android.mk
+        'SK_DEBUG',
+        'SK_DEVELOPER=1',
+      ],
+      'libraries!': [
+        '-lstdc++',
+        '-lm',
+      ],
+      'include_dirs!': [

[djsollen, 2014/01/21 17:47:37]

who generates these?

[scroggo, 2014/01/21 19:10:06]

core.gyp. They've been there since the start (see
https://codereview.appspot.com/4282056/). I'm not sure what they refer to, since
we don't have toplevel folders named config or ext.

+        'config',
+        'ext',
+      ],
+    }],
 
     [ 'skia_os in ["linux", "freebsd", "openbsd", "solaris", "nacl", "chromeos"]',
       {