Update SK_API to support non-Windows DLLs.

Update SK_API to support non-Windows DLLs.

On non-Windows platforms, use the visibility annotation to
export API symbols.

[reed1, 2011-04-26 11:38:53]

How do I test this? Is there a tweak to our Makefile, or some other config to
exercise this?

[evan, 2011-04-26 16:45:14]

On 2011/04/26 11:38:53, reed1 wrote:
> How do I test this? Is there a tweak to our Makefile, or some other config to
> exercise this?

I'm trying to make the Chrome "components" build work, which is where we build
some libraries as separate DLLs.  (This is useful during development because it
speeds up linking.)  Skia is one library that is self-contained enough to make
this work.

But the components work has only been done on Windows so far, so I'm working on
non-Windows support.  To test this you need to build Skia with SKIA_DLL defined,
as well as adjusting your build system to link a .so instead of a .a file.  I'm
not actually sure what build system you normally use for Skia!

In Chrome's case, you run gyp with the -Dcomponent=shared_library flag, rebuild,
and you should still produce working executables that "ldd" says depend on a
newly-built libskia.so.

[reed1, 2011-04-26 19:05:41]

LGTM

BWT - skia has a makefile that builds the library + a set of tools. You could
modify the Makefile to (optionally or not) build the library as a shraredlib.
That way the skia engineers will know if we break your config. Our makefile
works for mac and linux (but not windows yet).

[evan, 2011-04-26 19:42:13]

Can you land this for me?

Thanks for the note -- I have locally modified the Makefile to add a SKIA_SHARED
build flag and will send you another change for it.  It seems to at least build
"bench"...

[reed1, 2011-04-26 20:04:31]

Committed revision 1192.