Add NaCl port of Skia

Add NaCl port of Skia

Initial commit. This is far from done.
Committed: https://code.google.com/p/skia/source/detail?r=5398

[EricB, 2012-09-04 16:43:20]

This makes the necessary changes to our build system in order to build under
NaCl and adds a sample.  There is still work that needs to be done before we can
add Skia to NaCl Ports.

[reed1, 2012-09-04 16:51:11]

WDIK (what do I know) -- deferring to elliot

[epoger, 2012-09-04 17:29:25]

On 2012/09/04 16:51:11, reed1 wrote:
> WDIK (what do I know) -- deferring to elliot

I know even less.

Eric, please grab me sometime tomorrow to discuss this live for a few minutes,
so I get a better understanding of the context.

[EricB, 2012-09-04 17:50:17]

I'll describe things briefly here, so that it's on the record.  I added a 'nacl'
directory as a sibling of trunk.  Everything inside this directory deals with a
sample NaCl application which happens to link against Skia.  For now, it's just
a dumb example that, when loaded as a plugin, uses Skia to draw a blue box with
a red box inside.  There's a barebones web server in httpd.py which serves
index.html, which requests that skia_nacl be loaded as a plugin.  The server
defers to the NaCl Manifest (skia_nacl.nmf) to determine which (32 or 64-bit)
version of skia_nacl to load.

In order to build skia_nacl, we have to build Skia inside of naclports
(http://code.google.com/p/naclports/).  This part isn't yet working smoothly,
but the idea is that, in naclports, a library is downloaded, built, and
installed to a fake /usr/lib directory inside your NaCl SDK by running a script.
 I have this working, but it's an ugly hack.  In order to compile Skia inside
naclports, I had to make the above gyp changes.

[epoger, 2012-09-04 18:38:04]

LGTM

Thanks for the explanation...

On 2012/09/04 17:50:17, EricB wrote:
> I'll describe things briefly here, so that it's on the record.  I added a
'nacl'
> directory as a sibling of trunk.  Everything inside this directory deals with
a
> sample NaCl application which happens to link against Skia.  For now, it's
just
> a dumb example that, when loaded as a plugin, uses Skia to draw a blue box
with
> a red box inside.  There's a barebones web server in httpd.py which serves
> index.html, which requests that skia_nacl be loaded as a plugin.  The server
> defers to the NaCl Manifest (skia_nacl.nmf) to determine which (32 or 64-bit)
> version of skia_nacl to load.
> 
> In order to build skia_nacl, we have to build Skia inside of naclports
> (http://code.google.com/p/naclports/).  This part isn't yet working smoothly,
> but the idea is that, in naclports, a library is downloaded, built, and
> installed to a fake /usr/lib directory inside your NaCl SDK by running a
script.
>  I have this working, but it's an ugly hack.  In order to compile Skia inside
> naclports, I had to make the above gyp changes.

So, if I understand this right...

- The Makefile added here is for building the sample NaCl application
(skia_nacl) which happens to use the Skia library.  You need to put this
Makefile, manifest, etc. within the naclports environment in order for it to
build.

- The gyp changes are required to build a skia library that will link properly
into the skia_nacl sample app.  (Even with these changes, the Skia library is
still built independently of the naclports environment.  Hence it can still use
our gyp framework, as opposed to the naclports repository, which doesn't appear
to use gyp.)

If the above is correct, I'm curious as to whether changes like these might be
needed for the Skia library to link against other calling code.  Why is nacl
different from Chrome, Android, etc. in these particular ways?  (No need to
answer that here; I just want to make sure that this is a valid QUESTION and I
don't have a fundamental misunderstanding of how this connects to naclports.)

[bungeman, 2012-09-04 18:49:26]

> I'm curious as to whether changes like these might be
> needed for the Skia library to link against other calling code.

http://code.google.com/p/skia/issues/detail?id=459

[EricB, 2012-09-04 18:53:52]

On 2012/09/04 18:38:04, epoger wrote:
> So, if I understand this right...
> 
> - The Makefile added here is for building the sample NaCl application
> (skia_nacl) which happens to use the Skia library.  You need to put this
> Makefile, manifest, etc. within the naclports environment in order for it to
> build.
> 

Correct, except that it can be built in place.  It just requires that libskia.a
exists in the right location inside your NaCl SDK.

> - The gyp changes are required to build a skia library that will link properly
> into the skia_nacl sample app.  (Even with these changes, the Skia library is
> still built independently of the naclports environment.  Hence it can still
use
> our gyp framework, as opposed to the naclports repository, which doesn't
appear
> to use gyp.)
> 

Correct.  The typical install process for a library in naclports is to download
a source tarball, unzip it, compile the sources, copy the libraries into the
NaCl SDK, and then clean up, deleting the sources and everything that was
downloaded.  This is the process that I have hacked up, because of the bug which
bungeman@ just posted.  Right now, I expose several of the libraries as
top-level targets via an on-the-fly patch, build those targets, grep for the
object files produced in building them, and wrap those up in a new libskia.a.  I
guess I'll have to tackle issue #459 next.

Most of these changes have to do with NaCl's sandboxing not giving us access to
typical system stuff, so they belong inside the conditionals.