Generate Android.mk for DM.

Generate Android.mk for DM.

ifdef out code that won't build where we don't have jsoncpp.

Include ctype instead of string.h for tolower.

Depends on https://codereview.chromium.org/282053002/

BUG=skia:2447
Committed: http://code.google.com/p/skia/source/detail?r=14768

[mtklein, 2014-05-15 22:17:47]

LGTM

Dare I ask: why?

https://codereview.chromium.org/290603002/diff/1/gyp/dm.gyp
File gyp/dm.gyp (right):

https://codereview.chromium.org/290603002/diff/1/gyp/dm.gyp#newcode63
gyp/dm.gyp:63: ['skia_android_framework == 1',
just 'skia_android_framework' has the same effect right?

https://codereview.chromium.org/290603002/diff/1/gyp/dm.gyp#newcode67
gyp/dm.gyp:67: '-lcutils',
What comes with -lcutils?  Is that libc?

[mtklein, 2014-05-15 22:25:11]

Would it help the cause to do our JSON in-house rather than using jsoncpp? 
Seems like a fun weekend project.  Looks like we had an old hack SkJSON that no
one was using?

[scroggo, 2014-05-16 13:39:21]

On 2014/05/15 22:17:47, mtklein wrote:
> LGTM
> 
> Dare I ask: why?

Haha, why not? If DM is going to replace GM (and everything else), we ought to
be able
to build and run it using the framework Skia. If not, it just gives us all the
benefits
of DM we already get from it for the framework Skia.

On 2014/05/15 22:25:11, mtklein wrote:
> Would it help the cause to do our JSON in-house rather than using jsoncpp? 
> Seems like a fun weekend project.

It wouldn't hurt. That said, the reason I'm skipping JSON is an organizational
problem,
rather than a technical problem. I should be able to get it using jsoncpp, but I
didn't
want it to slow me down when we could already be building all these on Android.

> Looks like we had an old hack SkJSON that no one was using?

Interesting. Was it a wrapper around some existing library, or did we have our
own
implementation?

https://codereview.chromium.org/290603002/diff/1/gyp/dm.gyp
File gyp/dm.gyp (right):

https://codereview.chromium.org/290603002/diff/1/gyp/dm.gyp#newcode63
gyp/dm.gyp:63: ['skia_android_framework == 1',
On 2014/05/15 22:17:48, mtklein wrote:
> just 'skia_android_framework' has the same effect right?

Yes. We are very inconsistent about comparing to 1 versus just checking the
variable directly. Personally I'm not a huge fan of the unnecessary ' == 1' bit,
but I must have been looking at other cases of it when I wrote this one. It's
probably cleaner without it, and as clean as this file is, perhaps it's worth
removing.

https://codereview.chromium.org/290603002/diff/1/gyp/dm.gyp#newcode67
gyp/dm.gyp:67: '-lcutils',
On 2014/05/15 22:17:48, mtklein wrote:
> What comes with -lcutils?  Is that libc?

Yes.

[mtklein, 2014-05-16 13:48:35]

So are we going to have (or do we have?) bots running against framework-Skia?

[scroggo, 2014-05-16 13:55:20]

On 2014/05/16 13:48:35, mtklein wrote:
> So are we going to have (or do we have?) bots running against framework-Skia?

Glad you asked - yes! The Android build team builds each new Skia revision, and
skbug.com/2454 tracks actually running the tests (which we'll do inside our
infrastructure).

[scroggo, 2014-05-16 18:06:08]

The CQ bit was checked by scroggo@google.com

[commit-bot: I haz the power, 2014-05-16 18:06:55]

CQ is trying da patch. Follow status at
 https://skia-tree-status.appspot.com/cq/scroggo@google.com/290603002/60001

[commit-bot: I haz the power, 2014-05-16 18:11:54]

Change committed as 14768