Upstream version 10.39.225.0

[platform/framework/web/crosswalk.git] / src / native_client_sdk / src / doc / devguide / tutorial / tutorial-part2.rst

diff --git a/src/native_client_sdk/src/doc/devguide/tutorial/tutorial-part2.rst b/src/native_client_sdk/src/doc/devguide/tutorial/tutorial-part2.rst
index 91c9377..6cee489 100644 (file)
--- a/src/native_client_sdk/src/doc/devguide/tutorial/tutorial-part2.rst
+++ b/src/native_client_sdk/src/doc/devguide/tutorial/tutorial-part2.rst
@@ -14,11 +14,10 @@ Overview
 
 This tutorial shows how to convert the finished PNaCl web application from
 :doc:`Part 1 <tutorial-part1>` to use the Native Client SDK build system and
-common JavaScript files. It also demonstrates some techniques to make your
-web application `Content Security Policy (CSP)-compliant
-<http://developer.chrome.com/apps/contentSecurityPolicy.html>`, which is
-necessary for `Chrome Apps
-<https://developer.chrome.com/apps/about_apps.html>`_.
+common JavaScript files. It also demonstrates some techniques to make your web
+application `Content Security Policy (CSP)-compliant
+</apps/contentSecurityPolicy>`_, which is necessary for `Chrome Apps
+</apps/about_apps>`_.
 
 Using the Native Client SDK build system makes it easy to build with all of the
 SDK toolchains, and switch between the Debug and Release configurations. It
@@ -69,7 +68,9 @@ Glibc NaCl) and two configurations (Debug, Release).
 
     $(foreach src,$(SOURCES),$(eval $(call COMPILE_RULE,$(src),$(CFLAGS))))
 
-    ifeq ($(CONFIG),Release)
+    # The PNaCl workflow uses both an unstripped and finalized/stripped binary.
+    # On NaCl, only produce a stripped binary for Release configs (not Debug).
+    ifneq (,$(or $(findstring pnacl,$(TOOLCHAIN)),$(findstring Release,$(CONFIG))))
     $(eval $(call LINK_RULE,$(TARGET)_unstripped,$(SOURCES),$(LIBS),$(DEPS)))
     $(eval $(call STRIP_RULE,$(TARGET),$(TARGET)_unstripped))
     else
@@ -149,8 +150,8 @@ LIBS
   search path is already set up to only look in the directory for the current
   toolchain and architecture. In this example, we link against ``ppapi_cpp``
   and ``ppapi``. ``ppapi_cpp`` is needed to use the `Pepper C++ interface
-  <https://developers.google.com/native-client/peppercpp/>`_. ``ppapi`` is
-  needed for communicating with the browser.
+  </native-client/pepper_stable/cpp/>`_. ``ppapi`` is needed for communicating
+  with the browser.
 
 CFLAGS
   A list of extra flags to pass to the compiler. In this example, we pass
@@ -182,7 +183,7 @@ will use the variables we've defined above.
 
     $(foreach src,$(SOURCES),$(eval $(call COMPILE_RULE,$(src),$(CFLAGS))))
 
-    ifeq ($(CONFIG),Release)
+    ifneq (,$(or $(findstring pnacl,$(TOOLCHAIN)),$(findstring Release,$(CONFIG))))
     $(eval $(call LINK_RULE,$(TARGET)_unstripped,$(SOURCES),$(LIBS),$(DEPS)))
     $(eval $(call STRIP_RULE,$(TARGET),$(TARGET)_unstripped))
     else
@@ -206,11 +207,13 @@ example above, ``part2_arm.nexe``, ``part2_x86_32.nexe`` and
 ``part2_x86_64.nexe``.
 
 When ``CONFIG`` is ``Release``, each executable is also stripped to remove
-debug information and reduce the file size:
+debug information and reduce the file size. Otherwise, when the ``TOOLCHAIN``
+is ``pnacl``, the workflow involves creating an unstripped binary for debugging
+and then finalizing it and stripping it for publishing.
 
 .. naclcode::
 
-    ifeq ($(CONFIG),Release)
+    ifneq (,$(or $(findstring pnacl,$(TOOLCHAIN)),$(findstring Release,$(CONFIG))))
     $(eval $(call LINK_RULE,$(TARGET)_unstripped,$(SOURCES),$(LIBS),$(DEPS)))
     $(eval $(call STRIP_RULE,$(TARGET),$(TARGET)_unstripped))
     else
@@ -227,17 +230,16 @@ each executable generated in the previous step:
 Making index.html work for Chrome Apps
 ======================================
 
-This section describes the changes necessary to make the HTML and JavaScript
-in part1 CSP-compliant. This is required if you want to build a `Chrome App
-<https://developer.chrome.com/apps/about_apps.html>`_, but is not necessary
-if you want to use PNaCl on the open web.
+This section describes the changes necessary to make the HTML and JavaScript in
+part1 CSP-compliant. This is required if you want to build a `Chrome App
+</apps/about_apps>`_, but is not necessary if you want to use PNaCl on the open
+web.
 
 CSP rules
 ---------
 
-`Chrome Apps CSP
-<http://developer.chrome.com/apps/contentSecurityPolicy.html#what>`_
-restricts you from doing the following:
+`Chrome Apps CSP </apps/contentSecurityPolicy#what>`_ restricts you from doing
+the following:
 
 * You can’t use inline scripting in your Chrome App pages. The restriction
   bans both ``<script>`` blocks and event handlers (``<button onclick="...">``).
@@ -299,7 +301,9 @@ configurations, and path to the ``.nmf`` file:
 example with different toolchains by changing the URL's `query string
 <http://en.wikipedia.org/wiki/Query_string>`_. For example, you can load the
 glibc Debug version of this example by navigating to
-``index.html?tc=glibc&config=Debug``.
+``index.html?tc=glibc&config=Debug``.  Path URI's such as ``../``, for example
+do not work for either the data-path parameter or its corresponding query
+string.
 
 Next, we remove the ``embed`` element that is described in HTML. This will be
 automatically added for us by ``common.js``, based on the current
@@ -494,3 +498,14 @@ during the module loading process. This example only needs to respond to two:
       var logEl = document.getElementById('log');
       logEl.textContent += message.data;
     }
+    
+Compile the Native Client module and run the application again
+==============================================================
+
+#. Compile the Native Client module by running the ``make`` command again.
+#. Start the SDK web server by running ``make server``.
+#. Re-run the application by reloading ``http://localhost:5103/part2`` in 
+   Chrome.
+   
+   After Chrome loads the Native Client module, you should see the message sent
+   from the module.