Allow compiling PDFium without V8.

Allow compiling PDFium without V8.

Original patch from issue 1391843004 at patchset 1
(http://crrev.com/1391843004#ps1)

Introduce a pdf_enable_v8 GYP variable, which controls a
corresponding PDF_ENABLE_V8 #define, and bring in the real
JS library when set. Otherwise, link against a stub JS
runtime.

BUG=pdfium:211
R=dml@google.com, jochen@chromium.org, thestig@chromium.org

Committed: https://pdfium.googlesource.com/pdfium/+/f1c713663192368d26031a4caed1f9705f4510af

[Tom Sepez, 2015-10-08 17:23:04]

tsepez@chromium.org changed reviewers:
+ dml@google.com, jochen@chromium.org, thestig@chromium.org

[Tom Sepez, 2015-10-08 17:39:06]

Here's my proposal for review.

[Tom Sepez, 2015-10-08 19:26:51]

https://codereview.chromium.org/1395733006/diff/60001/pdfium.gyp
File pdfium.gyp (right):

https://codereview.chromium.org/1395733006/diff/60001/pdfium.gyp#newcode681
pdfium.gyp:681: 'target_name': 'javascript_stub',
actually, I think I'll just use the javascript target, with different contents.

[Tom Sepez, 2015-10-08 20:23:43]

Awright, Lei, Jochen, David, let's review ps6.

[David Lattimore, 2015-10-08 21:11:54]

lgtm

Thanks for doing this.

https://codereview.chromium.org/1395733006/diff/100001/fpdfsdk/src/javascript...
File fpdfsdk/src/javascript/JS_Runtime_Stub.cpp (right):

https://codereview.chromium.org/1395733006/diff/100001/fpdfsdk/src/javascript...
fpdfsdk/src/javascript/JS_Runtime_Stub.cpp:122: IJS_Runtime* m_pRuntime;
This doesn't seem to be used.

https://codereview.chromium.org/1395733006/diff/100001/fpdfsdk/src/javascript...
fpdfsdk/src/javascript/JS_Runtime_Stub.cpp:157: std::vector<CJS_ContextStub*>
m_ContextStack;
It looks like you could have a single CJS_ContextStub instead of a stack of them
since they appear to be stateless. The only caveat would be if the contexts get
used as keys in a map.

[Tom Sepez, 2015-10-08 21:25:33]

https://codereview.chromium.org/1395733006/diff/100001/fpdfsdk/src/javascript...
File fpdfsdk/src/javascript/JS_Runtime_Stub.cpp (right):

https://codereview.chromium.org/1395733006/diff/100001/fpdfsdk/src/javascript...
fpdfsdk/src/javascript/JS_Runtime_Stub.cpp:122: IJS_Runtime* m_pRuntime;
On 2015/10/08 21:11:54, David Lattimore wrote:
> This doesn't seem to be used.
removed.

https://codereview.chromium.org/1395733006/diff/100001/fpdfsdk/src/javascript...
fpdfsdk/src/javascript/JS_Runtime_Stub.cpp:157: std::vector<CJS_ContextStub*>
m_ContextStack;
On 2015/10/08 21:11:54, David Lattimore wrote:
> It looks like you could have a single CJS_ContextStub instead of a stack of
them
> since they appear to be stateless. The only caveat would be if the contexts
get
> used as keys in a map.

Yes, but the question remains when to delete it.  We'd have to ref-count it or
some such.

[David Lattimore, 2015-10-08 21:29:42]

https://codereview.chromium.org/1395733006/diff/100001/fpdfsdk/src/javascript...
File fpdfsdk/src/javascript/JS_Runtime_Stub.cpp (right):

https://codereview.chromium.org/1395733006/diff/100001/fpdfsdk/src/javascript...
fpdfsdk/src/javascript/JS_Runtime_Stub.cpp:157: std::vector<CJS_ContextStub*>
m_ContextStack;
On 2015/10/08 21:25:33, Tom Sepez wrote:
> On 2015/10/08 21:11:54, David Lattimore wrote:
> > It looks like you could have a single CJS_ContextStub instead of a stack of
> them
> > since they appear to be stateless. The only caveat would be if the contexts
> get
> > used as keys in a map.
> 
> Yes, but the question remains when to delete it.  We'd have to ref-count it or
> some such.  

It couldn't just be owned by CJS_RuntimeStub?

[Tom Sepez, 2015-10-08 22:12:19]

On 2015/10/08 21:29:42, David Lattimore wrote:
>
https://codereview.chromium.org/1395733006/diff/100001/fpdfsdk/src/javascript...
> File fpdfsdk/src/javascript/JS_Runtime_Stub.cpp (right):
> 
>
https://codereview.chromium.org/1395733006/diff/100001/fpdfsdk/src/javascript...
> fpdfsdk/src/javascript/JS_Runtime_Stub.cpp:157: std::vector<CJS_ContextStub*>
> m_ContextStack;
> On 2015/10/08 21:25:33, Tom Sepez wrote:
> > On 2015/10/08 21:11:54, David Lattimore wrote:
> > > It looks like you could have a single CJS_ContextStub instead of a stack
of
> > them
> > > since they appear to be stateless. The only caveat would be if the
contexts
> > get
> > > used as keys in a map.
> > 
> > Yes, but the question remains when to delete it.  We'd have to ref-count it
or
> > some such.  
> 
> It couldnt just be owned by CJS_RuntimeStub?
Done.

[David Lattimore, 2015-10-08 22:15:38]

lgtm

[jochen (gone - plz use gerrit), 2015-10-09 09:51:59]

lgtm

[Tom Sepez, 2015-10-09 15:54:13]

On 2015/10/09 09:51:59, jochen wrote:
> lgtm
Lei, you want to sign off on the gyp/gn stuff?

[Lei Zhang, 2015-10-09 17:43:31]

On 2015/10/09 15:54:13, Tom Sepez wrote:
> On 2015/10/09 09:51:59, jochen wrote:
> > lgtm
> Lei, you want to sign off on the gyp/gn stuff?

The GN changes do not seem to match the gyp changes.

[Tom Sepez, 2015-10-09 17:57:57]

On 2015/10/09 17:43:31, Lei Zhang wrote:
> On 2015/10/09 15:54:13, Tom Sepez wrote:
> > On 2015/10/09 09:51:59, jochen wrote:
> > > lgtm
> > Lei, you want to sign off on the gyp/gn stuff?
> 
> The GN changes do not seem to match the gyp changes.
Right, I didn't think that GN needed to support this since only chrome builds
with GN, and chrome always has v8.

[Lei Zhang, 2015-10-09 18:04:48]

On 2015/10/09 17:57:57, Tom Sepez wrote:
> Right, I didn't think that GN needed to support this since only chrome builds
> with GN, and chrome always has v8.

We should keep the 2 build systems in sync, or at least add a note to indicate
there is a difference.

[Tom Sepez, 2015-10-09 19:37:43]

> We should keep the 2 build systems in sync, or at least add a note to indicate
> there is a difference.
Fair enough. GN now in sync with GYP.

[Lei Zhang, 2015-10-09 19:40:38]

lgtm

https://codereview.chromium.org/1395733006/diff/200001/pdfium.gni
File pdfium.gni (right):

https://codereview.chromium.org/1395733006/diff/200001/pdfium.gni#newcode1
pdfium.gni:1: # Copyright 2015 The Chromium Authors. All rights reserved.
PDFium?

[Tom Sepez, 2015-10-09 19:45:21]

Committed patchset #12 (id:220001) manually as
f1c713663192368d26031a4caed1f9705f4510af (presubmit successful).