Adding --no-nacl to gn disables nonsfi and sfi nacl from building.

Adding --no-nacl to gn disables nonsfi and sfi nacl from building.

Previously, "mojo_use_nacl" was SFI-specific. Now, it applies to both SFI and
non-SFI NaCl. Using the "--no-nacl" flag should set this variable to false,
disabling both SFI and non-SFI NaCl, as well as targets built by the PNaCl Newlib
toolchain.

This argument is NOT active by default, since we still want coverage of NaCl
within Mojo, but it should make non-NaCl Mojo compilation faster.

BUG=#483
R=phosek@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/bfc3419516e29718a782211d1d0ead70d1ed2174

[Sean Klein, 2015-11-13 18:58:23]

Description was changed from

==========
Adding --no-nacl to gn disables nonsfi and sfi nacl from building.

BUG=#483
==========

to

==========
Adding --no-nacl to gn disables nonsfi and sfi nacl from building.

Previously, "mojo_use_nacl" was SFI-specific. Now, it applies to both SFI and
non-SFI NaCl. Using the "--no-nacl" flag should set this variable to false,
disabling both SFI and non-SFI NaCl, as well as targets built by the PNaCl
Newlib
toolchain.

This argument is NOT active by default, since we still want coverage of NaCl
within Mojo, but it should make non-NaCl Mojo compilation faster.

BUG=#483
==========

[Sean Klein, 2015-11-13 18:59:05]

smklein@chromium.org changed reviewers:
+ phosek@chromium.org

[viettrungluu, 2015-11-13 19:01:09]

viettrungluu@chromium.org changed reviewers:
+ viettrungluu@chromium.org

[viettrungluu, 2015-11-13 19:01:09]

I don't think we should do this, since it just hides the problem.

I think we should prioritize making it faster.

[Sean Klein, 2015-11-13 19:03:16]

On 2015/11/13 19:01:09, viettrungluu wrote:
> I don't think we should do this, since it just hides the problem.
> 
> I think we should prioritize making it faster.

I will definitely prioritize making it faster, but I do not know how long that
will take. I am not very familiar with the PNaCl Newlib toolchain, and
profiling/fixing slow spots may take some time.
I just wanted a quicker fix for you, since you mentioned it was a pain.

(This is partially why I'm leaving "--no-nacl" as off by default)

[viettrungluu, 2015-11-13 19:07:22]

On 2015/11/13 19:03:16, smklein1 wrote:
> On 2015/11/13 19:01:09, viettrungluu wrote:
> > I don't think we should do this, since it just hides the problem.
> > 
> > I think we should prioritize making it faster.
> 
> I will definitely prioritize making it faster, but I do not know how long that
> will take. I am not very familiar with the PNaCl Newlib toolchain, and
> profiling/fixing slow spots may take some time.
> I just wanted a quicker fix for you, since you mentioned it was a pain.

I'm willing to put up with some pain, as long as it's being prioritized. You may
just have to endure periodic fits of rage from me. :P

But experience (e.g., in Chromium) suggests that allowing things to be turned
off mostly results in those things not being improved.

> 
> (This is partially why I'm leaving "--no-nacl" as off by default)

[Petr Hosek, 2015-11-13 19:39:47]

> I'm willing to put up with some pain, as long as it's being prioritized. You
may
> just have to endure periodic fits of rage from me. :P
> 
> But experience (e.g., in Chromium) suggests that allowing things to be turned
> off mostly results in those things not being improved.

I completely agree and I'll put this at the top of our priority list. The
solution for this problem is to add support for dynamic linking into our
toolchain. We should definitely start working on that one, but it's not
something that'll be ready in a week, it's more likely going to be our Q1 OKR.

[Petr Hosek, 2015-11-13 19:54:26]

lgtm

[Sean Klein, 2015-11-16 22:05:10]

Patchset #2 (id:20001) has been deleted

[Sean Klein, 2015-11-16 22:12:05]

Committed patchset #1 (id:1) manually as
bfc3419516e29718a782211d1d0ead70d1ed2174 (presubmit successful).