Enable untrusted GYP builds in Chrome (irt via gyp)

Enable untrusted GYP builds in Chrome (irt via gyp)

Reconstruct of CL to enable untrsuted builds see:
  http://codereview.chromium.org/8416025.

This CL will enable untrusted builds in Chrome.  The first step
is to enable enable building the IRT via this technique instead
of using scons.

DEPS:
  We bump NaCl deps to fix untrusted.gypi in NaCl Repo

ppapi/ppapi_cpp.gypi+
  Add ppapi_cpp library for NEXE

ppapi/native_client/native_client.gyp
  Add ppapi library for NEXE (copy linker script to toolchain dir)
  Add nacl_irt target (the actual IRT.NEXE)

ppapi/ppapi.gyp & ppapi/ppapi_internal.gyp
  Pull in untrusted.gypi from NaCl repo

ppapi/native_client/src/shared/ppapi_proxy/ppapi_proxy.gyp
  Add ppruntime library for NEXE

chrome/nacl.gypi
  Remove scons header scan and scons irt build
  Add dependency to untrusted IRT build in native_client.gyp


BUG= http://code.google.com/p/chromium/issues/detail?id=96782
TEST= try
TBR=dmichael@chromium.org
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=109739

[noelallen1, 2011-11-11 18:26:21]

Okay, I have tested this, then split this into two CLs.  This CL switches us to
building IRT via GYP.  The second CL:
  http://codereview.chromium.org/8539019/

Actually builds ppapi_uitests as a NEXE.

I have this as two CLs in case something goes flaky with ppapi_uitests (for
example the 64 bit Linux issue), so that the whole CL won't be reverted.

[bradn, 2011-11-11 19:43:57]

lgtm

[dmichael (off chromium), 2011-11-11 23:57:19]

Lgtm
On Nov 11, 2011 12:43 PM, <bradnelson@google.com> wrote:

> lgtm
>
>
>
>
http://codereview.chromium.**org/8502036/<http://codereview.chromium.org/8502...
>

[jamesr, 2011-11-22 02:06:53]

Why on earth should ppapi depend on nacl? Isn't that backwards?

This is very difficult to deal with in WebKit where we depend on ppapi but we
don't want to depend on nacl.

[noelallen1, 2011-11-22 02:26:10]

On 2011/11/22 02:06:53, jamesr wrote:
> Why on earth should ppapi depend on nacl? Isn't that backwards?
> 
> This is very difficult to deal with in WebKit where we depend on ppapi but we
> don't want to depend on nacl.

NaCl is the main consumer, since most PPAPI developers will be providing
untrusted plugins not trusted plugins.

However, as you say, PPAPI in theory doesn't depend on Chrome.
However our PPAPI tests do, and the untrusted version uses the same source files
as the C++ interface for PPAPI which is how ppapi_internal.gyp and ppapi.gyp
respectively got "tainted" with untrusted.gypi.

Does WebKit use ppapi_internal, or just ppapi.gyp?   And does it use only
ppapi_c or both ppapi_c and ppapi_cpp?

Once we know what pieces are actually used by WebKit, we should be able to
create a new CL to "hide" untrusted implementations.

[scottmg, 2011-11-22 03:07:14]

On 2011/11/22 02:26:10, noelallen1 wrote:
> On 2011/11/22 02:06:53, jamesr wrote:
> > Why on earth should ppapi depend on nacl? Isn't that backwards?
> > 
> > This is very difficult to deal with in WebKit where we depend on ppapi but
we
> > don't want to depend on nacl.
> 
> NaCl is the main consumer, since most PPAPI developers will be providing
> untrusted plugins not trusted plugins.
> 
> However, as you say, PPAPI in theory doesn't depend on Chrome.
> However our PPAPI tests do, and the untrusted version uses the same source
files
> as the C++ interface for PPAPI which is how ppapi_internal.gyp and ppapi.gyp
> respectively got "tainted" with untrusted.gypi.
> 
> Does WebKit use ppapi_internal, or just ppapi.gyp?   And does it use only
> ppapi_c or both ppapi_c and ppapi_cpp?

The DEPS file (e.g.
http://git.chromium.org/gitweb/?p=external/WebKit_trimmed.git;a=blob;f=Source...)
only includes ppapi.gyp.

I don't know which of ppapi_c/_cpp it uses.

There's a roll containing an empty untrusted.gypi here:
https://bugs.webkit.org/show_bug.cgi?id=72911 which I think we should commit (at
least as a temporary measure?) as currently this is masking another DEPS failure
farther along.

[scottmg, 2011-11-22 03:15:12]

> There's a roll containing an empty untrusted.gypi here:
> https://bugs.webkit.org/show_bug.cgi?id=72911 which I think we should commit
(at
> least as a temporary measure?) as currently this is masking another DEPS
failure
> farther along.

Scratch that, webkit won't apply the "empty file" hack because of .ignores that
it (sensibly) doesn't want in those locations. So, I think we should probably
figure out a real fix. Dirk (see WK bug) is working on a different workaround.

[noelallen_use_chromium, 2011-11-22 03:18:49]

On 2011/11/22 03:15:12, scottmg wrote:
> > There's a roll containing an empty untrusted.gypi here:
> > https://bugs.webkit.org/show_bug.cgi?id=72911 which I think we should commit
> (at
> > least as a temporary measure?) as currently this is masking another DEPS
> failure
> > farther along.
> 
> Scratch that, webkit won't apply the "empty file" hack because of .ignores
that
> it (sensibly) doesn't want in those locations. So, I think we should probably
> figure out a real fix. Dirk (see WK bug) is working on a different workaround.

For a solution, if only ppapi.gyp is used, and there are no references to the
ppapi.gyp:ppapi_cpp target (which gets included via ppapi_cpp.gypi) then I would
promote ppapi_cpp.gypi to ppapi_cpp.gyp, upgate all references of
ppapi.gyp:ppapi_cpp to ppapi_cpp.gyp:ppapi_cpp and remove the include of
untrusted.gypi from ppapi.gyp

If either you can drop by and help me figure out how to test it, I'm happy to
help with the change first thing tomorrow.  Unfortunately I've never done any
WebKit gardening, or had a WebKit client, so I would need a hand verifying.

[nduca, 2011-11-22 08:34:42]

Can we revert this change while we figure out how to fix this? This is making it
impossible for anyone landing webkit changes to make progress. That's not an
acceptable state of affairs.