Expose debugger backend classes externally.

Expose debugger backend classes externally.

SkDebugCanvas & friends are useful beyond the Qt debugger app - Chromium's picture inspector (in development) is at the point where it could take advantage of it.

This patch moves SkDrawCommand, SkDebugCanvas & SkObjectParser from trunk/debugger to trunk/src/utils (since several tools already use these, this seems appropriate), and makes SkDrawCommand & SkDebugCanvas' symbols visible externally (SK_API).

R=reed@google.com

Committed: https://code.google.com/p/skia/source/detail?r=9598

[djsollen, 2013-06-11 20:49:27]

I'm fine with this change and it will help me enable some of the tools on
Android as we don't have the debugger directory there.

[reed1, 2013-06-11 21:34:23]

src/utils is already crowded, and these seem to be rather specialized.

Can we make a new dir (or subdir inside utils) for these?

[reed1, 2013-06-11 21:34:47]

e.g. SkObjectParser is a pretty generic sounding class name. Can we be more
specific?

[robertphillips, 2013-06-11 21:40:00]

I would actually kind of like SkObjectParser to go away (and be folded into
individual class toString methods).

Additionally, I think the DrawCommand and DebugCanvas classes need some cleaning
up before they will be presentable.

I think it is okay to move them as is and clean them up later though.

[f(malita), 2013-06-11 21:46:41]

On 2013/06/11 21:34:23, reed1 wrote:
> src/utils is already crowded, and these seem to be rather specialized.
> 
> Can we make a new dir (or subdir inside utils) for these?

Sure - src/utils/debugging/ then?


On 2013/06/11 21:34:47, reed1 wrote:
> e.g. SkObjectParser is a pretty generic sounding class name. Can we be more
> specific?

Yup, generic and misleading (no parsing going on afaict). How about
SkDrawCommandPrinter?

[reed1, 2013-06-11 21:47:21]

src/utils/debugger is fine with me

[f(malita), 2013-06-11 22:12:04]

On 2013/06/11 21:40:00, robertphillips wrote:
> I would actually kind of like SkObjectParser to go away (and be folded into
> individual class toString methods).
> 
> Additionally, I think the DrawCommand and DebugCanvas classes need some
cleaning
> up before they will be presentable.
> 
> I think it is okay to move them as is and clean them up later though.

SGTM, I'll open an issue for tracking the cleanup.

[f(malita), 2013-06-13 17:44:13]

Can I get a rubber-stamp on this, if we're OK with this preliminary form?

[reed1, 2013-06-13 19:29:36]

lgtm

[commit-bot: I haz the power, 2013-06-13 19:48:17]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/fmalita@chromium.org/16638014/9001

[f(malita), 2013-06-13 20:19:58]

On 2013/06/13 19:48:17, I haz the power (commit-bot) wrote:
> CQ is trying da patch. Follow status at
> https://skia-tree-status.appspot.com/cq/fmalita%40chromium.org/16638014/9001

Them bots can't handle all the awesome sauce in this cl, so I'll cowboy-land it
and keep an eye on the waterfall.

[commit-bot: I haz the power, 2013-06-13 20:22:43]

Retried try job too often on Build-Ubuntu12-GCC-x86_64-Release-Trybot for
step(s) BuildBench, BuildGm, BuildMost, BuildSkiaLib, BuildTests, BuildTools
http://108.170.217.252:10117/buildstatus?builder=Build-Ubuntu12-GCC-x86_64-Re...

[f(malita), 2013-06-13 21:00:35]

Committed patchset #2 manually as r9598 (presubmit successful).