From c3e44d6a8d69d8870b5bdc0d71ffe71891c97148 Mon Sep 17 00:00:00 2001
From: jmedley examples
directory where you sta
server. For example, to run the flock
example in the SDK, start the server
and point your browser to http://localhost:5103/demo/flock/
.
Some of the applications need special flags to Chrome, and must be run with the
-make run
command. See Run the SDK examples for more details.
make run
command. See Run the SDK examples for more details.
Applications published in the Chrome Web Store must be accompanied by CWS
metadata; specifically, a Chrome Web Store manifest file named
diff --git a/native_client_sdk/doc_generated/devguide/tutorial/tutorial-part2.html b/native_client_sdk/doc_generated/devguide/tutorial/tutorial-part2.html
index 47dddbd..08a753b 100644
--- a/native_client_sdk/doc_generated/devguide/tutorial/tutorial-part2.html
+++ b/native_client_sdk/doc_generated/devguide/tutorial/tutorial-part2.html
@@ -37,7 +37,7 @@ application Con
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
also simplifies the makefiles for your project, as we’ll see in the next
-section. Finally, it adds some useful commands for running and debugging
+section. Finally, it adds some useful commands for running and debugging
your application. The finished code for this example can be found in the
To build Native Client modules, you must download and install the Native Client
-Software Development Kit (SDK). This page provides an overview of the Native
-Client SDK, and instructions for how to download and install the SDK. This page provides an overview of the Native Client SDK, and instructions for
+downloading and installing the SDK. The Native Client SDK includes the following: The Native Client SDK includes: Follow the steps below to download and install the Native Client SDK. Make sure that the Python executable is in your Python 2.6 or 2.7: Make sure that the Python executable is in your path.
-Python 2.7 is preferred. Python 3.x is not yet supported. Download the SDK update zip file: nacl_sdk.zip. Download the SDK update zip file. Unzip the file: On Mac/Linux, run the command “ On Mac/Linux, run the command On Windows, right-click on the .zip file and select “Extract All...”. A
-dialog box will open; enter a location and click “Extract”. A directory is created called To see the SDK bundles that are available for download, go to the
-pepper_$(VERSION)/getting_started/part2
directory in the Native Client SDK
diff --git a/native_client_sdk/doc_generated/sdk/download.html b/native_client_sdk/doc_generated/sdk/download.html
index 8a57dbc..d5b35ea 100644
--- a/native_client_sdk/doc_generated/sdk/download.html
+++ b/native_client_sdk/doc_generated/sdk/download.html
@@ -2,18 +2,16 @@
Download the Native Client SDK
-Overview
-Overview
+
Prerequisites
+Prerequisites
+Python 2.7
+PATH
variable. Python 3.x is
+not yet supported.
-
-
-python
--V
” in a terminal window, and make sure that the version you have is 2.6.x
-or 2.7.x.C:\python27
) to the PATH environment
-variable. Run
-“python -V
” from a command line to verify that you properly configured
-the PATH variable.python -V
+in a terminal window, and make sure that the version you have is 2.6.x or
+2.7.x.C:\python27
) to the PATH
environment variable. Run python -V
from a command line to
+verify that you properly configured the PATH variable.make
command on your system
-before you can build and run the examples in the SDK. One easy way to get
-make
, along with several other useful tools, is to install
-Xcode Developer Tools.
-After installing Xcode, go to the XCode menu, open the Preferences dialog box
-then select Downloads and Components. Verify that Command Line Tools are
-installed. If you’d rather not install Xcode, you can download and build an
-open source version of make
.
-To build the command you may also need to download and install
-gcc.Make
+
+
-make
on your system before you can build
+and run the examples in the SDK. One easy way to get make
, along with
+several other useful tools, is to install Xcode Developer Tools. After installing Xcode,
+go to the XCode menu, open the Preferences dialog box then select Downloads
+and Components. Verify that Command Line Tools are installed. If you’d rather
+not install Xcode, you can download and build an open source version of make
.
+To build the program you may also need to download and install gcc.Installing the SDK
+Installing the SDK
+Downloading and Unzipping
-
-
unzip nacl_sdk.zip
” in a terminal
+unzip nacl_sdk.zip
in a terminal
window.nacl_sdk
with the following files and
@@ -79,11 +75,11 @@ you have already downloaded.Installing bundles
+Installing the stable bundle
nacl_sdk
directory and run naclsdk
with the “list
” command. The
-SDK includes a separate bundle for each version of Chrome/Pepper.nacl_sdk
directory and run naclsdk
with the list
command. The SDK
+includes a separate bundle for each version of Chrome/Pepper.
On Mac/Linux:
$ cd nacl_sdk @@ -114,16 +110,18 @@ Bundles:
The sample output above shows that several bundles are available for
download, and that you have already installed the latest revision of the
-sdk_tools
bundle. (It was included in the zip file you downloaded.) Each
-bundle is labeled post-stable, stable, beta, dev, or canary. These labels
-usually correspond to the current versions of Chrome.
We recommend that you download and use a “stable” bundle, because
-applications developed with “stable” bundles can be used by all current
-Chrome users. This is because Native Client is designed to be
-backward-compatible (for example, applications developed with the
-pepper_31
bundle can run in Chrome 31, Chrome 32, etc.).
sdk_tools
bundle, which was included in the zip file. You never need to
+update the sdk_tools
bundle. It is updated automatically (if necessary)
+whenever you run naclsdk
.
+Bundles are labeled post-stable, stable, beta, dev, or canary. These labels
+usually correspond to the current versions of Chrome. We recommend that you
+develop against a “stable” bundle, because such bundles can be used by all
+current Chrome users. Native Client is designed to be backward-compatible.For
+example, applications developed with the pepper_31
bundle can run in
+Chrome 31, Chrome 32, etc..
Run naclsdk
with the “update” command to download recommended bundles.
Run naclsdk
with the update
command to download recommended bundles,
+including the current “stable” bundle.
On Mac/Linux:
$ ./naclsdk update @@ -132,25 +130,18 @@ $ ./naclsdk update> naclsdk update-By default,
+naclsdk
only downloads bundles that are recommended— -generally those that are “stable.” Continuing with the earlier example, the -“update” command would only download thepepper_35
bundle, since the -bundlespepper_36
and greater are not yet stable. If you want the -pepper_36
bundle, you must ask for it explicitly:By default,
naclsdk
only downloads bundles that are recommended, +generally those that are “stable.” For example, if the current “stable” +bundle ispepper_35
, then theupdate
downloads that bundle. To +download thepepper_36
bundle you must ask for it explicitly:$ ./naclsdk update pepper_36
Run naclsdk
with the “list” command. This shows you the list of available
+
Run naclsdk
with the list
command. This shows you the list of available
bundles and verifies which bundles you have installed.
On Mac/Linux:
@@ -160,7 +151,8 @@ $ ./naclsdk list> naclsdk list-If an update is available, you’ll see something like this.:
+An asterisk (*) next to a bundle indicates that there is an update available +it. For example:
Bundles: I: installed @@ -178,8 +170,7 @@ Bundles: pepper_canary (canary) bionic_canary (canary)-An asterisk next to a bundle indicates that there is an update available it. -If you run “
naclsdk update
” now, it warns you with a message similar to +If you run
naclsdk update
now, it warns you with a message similar to this:WARNING: pepper_35 already exists, but has an update available. Run update @@ -198,7 +189,7 @@ $ ./naclsdk update --force
naclsdk
utilitynaclsdk
utilityFor more information about the naclsdk
utility, run:
On Mac/Linux:
@@ -211,14 +202,14 @@ $ ./naclsdk helpNext steps:
+Every Native Client SDK bundle comes with a folder of example applications. Each example demonstrates one or two key Native Client programming concepts. After you’ve downloaded the SDK, follow the instructions on this page to build and run the examples.
Your version of Chrome must be equal to or greater than the version of your SDK
-bundle. For example, if you’re developing with the pepper_31
bundle, you
-must use Google Chrome version 31 or greater. To find out what version of Chrome
+bundle. For example, if you’re developing with the pepper_35
bundle, you
+must use Google Chrome version 35 or greater. To find out what version of Chrome
you’re using, type about:chrome
or about:version
in the Chrome address
bar.
To run Portable Native Client applications you must specifically enable Native -Client in Chrome:
+If you are using Chrome 31 or later, you can skip this section. To run Portable +Native Client applications you must specifically enable Native Client in Chrome:
Type about:flags
in the Chrome address bar and scroll down to “Native
Client”.
Chrome caches resources aggressively. When you are building a Native Client -application you should disable the cache to make sure that Chrome loads the -latest version.
-The Makefile scripts for the SDK examples build multiple versions of the -examples using all three SDK toolchains (newlib, glibc, and PNaCl) and in both -release and debug configurations. (Note that some examples build only with -particular toolchains).
-To build all the examples, go to the examples directory in a specific SDK
-bundle and run make
:
The Makefile scripts for the SDK examples can build multiple versions of the
+examples using any of the three SDK toolchains (newlib, glibc, and PNaCl) and in
+both release and debug configurations. Note that some examples, dlopen
for
+example, build only with particular toolchains.
Find the toolchains for each example by looking at the VALID_TOOLCHAINS
+variable in the Makefile for a particular example. The first item listed is the
+default. It’s built when you run an example make file without parameters. for
+example running make in the core
directory of pepper_35 builds the example
+using the newlib
toolchain.
-$ cd pepper_31/examples +$ cd pepper_35/examples/api/core $ make -make -C api all -make[1]: Entering directory `pepper_31/examples/api' -make -C audio all -make[2]: Entering directory `pepper_31/examples/api/audio' - CXX newlib/Debug/audio_x86_32.o - LINK newlib/Debug/audio_x86_32.nexe - CXX newlib/Debug/audio_x86_64.o - LINK newlib/Debug/audio_x86_64.nexe - CXX newlib/Debug/audio_arm.o - LINK newlib/Debug/audio_arm.nexe - CREATE_NMF newlib/Debug/audio.nmf -make[2]: Leaving directory `pepper_31/examples/api/audio' -make -C url_loader all -make[2]: Entering directory `pepper_31/examples/api/url_loader' - CXX newlib/Debug/url_loader_x86_32.o -... + CXX newlib/Release/core_x86_32.o + LINK newlib/Release/core_unstripped_x86_32.nexe + VALIDATE newlib/Release/core_unstripped_x86_32.nexe + CXX newlib/Release/core_x86_64.o + LINK newlib/Release/core_unstripped_x86_64.nexe + VALIDATE newlib/Release/core_unstripped_x86_64.nexe + CXX newlib/Release/core_arm.o + LINK newlib/Release/core_unstripped_arm.nexe + VALIDATE newlib/Release/core_unstripped_arm.nexe + STRIP newlib/Release/core_x86_32.nexe + STRIP newlib/Release/core_x86_64.nexe + STRIP newlib/Release/core_arm.nexe + CREATE_NMF newlib/Release/core.nmf-
Calling make
from inside a particular example’s directory will build only
-that example:
As you can see, this produces a number of architecture specific nexe files in
+the pepper_35/examples/api/core/Release
directory. Create debug versions by
+using the CONFIG
parameter of the make command.
-$ cd pepper_31/examples/api/core -$ make - CXX newlib/Debug/core_x86_32.o - LINK newlib/Debug/core_x86_32.nexe - CXX newlib/Debug/core_x86_64.o - LINK newlib/Debug/core_x86_64.nexe - CXX newlib/Debug/core_arm.o - LINK newlib/Debug/core_arm.nexe - CREATE_NMF newlib/Debug/core.nmf +$make CONFIG=Debug-
You can call make
with the TOOLCHAIN
and CONFIG
parameters to
-override the defaults:
This creates similar output, but in pepper_35/examples/api/core/Debug
.
Select a different toolchain with the TOOLCHAIN
parameter. For example:
+$ cd pepper_35/examples/api/core $ make TOOLCHAIN=pnacl CONFIG=Release - CXX pnacl/Release/core_pnacl.o - LINK pnacl/Release/core.bc - FINALIZE pnacl/Release/core.pexe + CXX pnacl/Release/core.o + LINK pnacl/Release/core_unstripped.bc + FINALIZE pnacl/Release/core_unstripped.pexe CREATE_NMF pnacl/Release/core.nmf-
You can also set TOOLCHAIN
to “all” to build one or more examples with
-all available toolchains:
You can also set TOOLCHAIN
to all
to build all Release versions with
+default toolchains.
+$ cd pepper_35/examples/api/core $ make TOOLCHAIN=all make TOOLCHAIN=newlib -make[1]: Entering directory `pepper_31/examples/api/core' - CXX newlib/Debug/core_x86_32.o - LINK newlib/Debug/core_x86_32.nexe - CXX newlib/Debug/core_x86_64.o - LINK newlib/Debug/core_x86_64.nexe - CXX newlib/Debug/core_arm.o - LINK newlib/Debug/core_arm.nexe - CREATE_NMF newlib/Debug/core.nmf -make[1]: Leaving directory `pepper_31/examples/api/core' +make[1]: Entering directory 'pepper_35/examples/api/core' + CXX newlib/Release/core_x86_32.o + LINK newlib/Release/core_unstripped_x86_32.nexe + VALIDATE newlib/Release/core_unstripped_x86_32.nexe + CXX newlib/Release/core_x86_64.o + LINK newlib/Release/core_unstripped_x86_64.nexe + VALIDATE newlib/Release/core_unstripped_x86_64.nexe + CXX newlib/Release/core_arm.o + LINK newlib/Release/core_unstripped_arm.nexe + VALIDATE newlib/Release/core_unstripped_arm.nexe + STRIP newlib/Release/core_x86_32.nexe + STRIP newlib/Release/core_x86_64.nexe + STRIP newlib/Release/core_arm.nexe + CREATE_NMF newlib/Release/core.nmf +make[1]: Leaving directory 'pepper_35/examples/api/core' make TOOLCHAIN=glibc -make[1]: Entering directory `pepper_31/examples/api/core' - CXX glibc/Debug/core_x86_32.o - LINK glibc/Debug/core_x86_32.nexe - CXX glibc/Debug/core_x86_64.o - LINK glibc/Debug/core_x86_64.nexe - CREATE_NMF glibc/Debug/core.nmf -make[1]: Leaving directory `pepper_31/examples/api/core' -make TOOLCHAIN=pnacl -make[1]: Entering directory `pepper_31/examples/api/core' - CXX pnacl/Debug/core.o - LINK pnacl/Debug/core_unstripped.bc - FINALIZE pnacl/Debug/core_unstripped.pexe - CREATE_NMF pnacl/Debug/core.nmf -make[1]: Leaving directory `pepper_31/examples/api/core' -make TOOLCHAIN=linux -make[1]: Entering directory `pepper_31/examples/api/core' - CXX linux/Debug/core.o - LINK linux/Debug/core.so -make[1]: Leaving directory `pepper_31/examples/api/core' +make[1]: Entering directory 'pepper_35/examples/api/core' + CXX glibc/Release/core_x86_32.o + LINK glibc/Release/core_unstripped_x86_32.nexe + VALIDATE glibc/Release/core_unstripped_x86_32.nexe + CXX glibc/Release/core_x86_64.o + LINK glibc/Release/core_unstripped_x86_64.nexe + VALIDATE glibc/Release/core_unstripped_x86_64.nexe + ... + (content excerpted) + ...-
After running make
, each example directory will contain one or more of
-the following subdirectories:
After running make
, example directories will contain one or more of the
+following subdirectories, depending on which Makefile you run:
newlib
with subdirectories Debug
and Release
;glibc
with subdirectories Debug
and Release
;To run the SDK examples, you can use the make run
command:
Chrome’s intelligent caching caches resources aggressively. When building a +Native Client application you should disable the cache to make sure that Chrome +loads the latest version. Intelligent caching only remains inactive while +Developer Tools are open. Otherwise, agressive caching continues.
+To run the SDK examples, use the make run
command:
-$ cd pepper_31/examples/api/core +$ cd pepper_35/examples/api/core $ make run-
This will launch a local HTTP server which will serve the data for the
-example. It then launches Chrome with the address of this server, usually
-http://localhost:5103
. After you close Chrome, the local HTTP server is
-automatically shutdown.
This command will try to find an executable named google-chrome
in your
+
This launches a local HTTP server that serves the example. It then launches
+Chrome with the address of this server, usually http://localhost:5103
.
+After you close Chrome, the local HTTP server automatically shuts down.
This command tries to find an executable named google-chrome
in your
PATH
environment variable. If it can’t, you’ll get an error message like
this:
-pepper_31/tools/common.mk:415: No valid Chrome found at CHROME_PATH= -pepper_31/tools/common.mk:415: *** Set CHROME_PATH via an environment variable, or command-line.. Stop. +pepper_35/tools/common.mk:415: No valid Chrome found at CHROME_PATH= +pepper_35/tools/common.mk:415: *** Set CHROME_PATH via an environment variable, or command-line.. Stop.+
Set the CHROME_PATH environment variable to the location of your Chrome executable.
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
for Chrome
stable and
C:\Users\<username>\AppData\Local\Google\Chrome SxS\Application\chrome.exe
-for Chrome Canary; try looking in those directories first:
+for Chrome Canary. Try looking in those directories first:
> set CHROME_PATH=<Path to chrome.exe>@@ -197,39 +185,36 @@ $ export CHROME_PATH=<Path to Google Chrome> -
You can run via a different toolchain or configuration by using the
-TOOLCHAIN
and CONFIG
parameters to make:
-$ make run TOOLCHAIN=pnacl CONFIG=Debug -
Each example can also be launched as a packaged app. For more information about -using Native Client for packaged apps, see Packaged application. For general information about packaged apps, see the -Chrome apps documentation.
+Each example can also be launched as a packaged application. A packaged +application is a special zip file (with a .crx extension) hosted in the Chrome +Web Store. This file contains all of the application parts: A Chrome Web Store +manifest file (manifest.json), an icon, and all of the regular Native Client +application files. Refer to What are Chrome Apps for more +information about creating a packaged application.
Some Pepper features, such as TCP/UDP socket access, are only allowed in
-packaged apps. The examples that use these features must be run as packaged
-apps, by using the make run_package
command:
$ make run_package-
You can use TOOLCHAIN
and CONFIG
parameters as above to run with a
-different toolchain or configuration.
You can use TOOLCHAIN
and CONFIG
parameters as described above to run
+with a different toolchain or configuration.
The NaCl SDK uses GDB to debug Native
Client code. The SDK includes a prebuilt version of GDB that is compatible with
NaCl code. To use it, run the make debug
command from an example directory:
$ make debug-
This will launch Chrome with the --enable-nacl-debug
flag set. This flag
-will cause Chrome to pause when a NaCl module is first loaded, waiting for a
-connection from gdb. The make debug
command also simultaneously launches
-GDB and loads the symbols for that NEXE. To connect GDB to Chrome, in the GDB
-console, type:
This launches Chrome with the --enable-nacl-debug
flag set. This flag causes
+Chrome to pause when a NaCl module is first loaded, waiting for a connection
+from gdb. The make debug
command also simultaneously launches GDB and loads
+the symbols for that NEXE. To connect GDB to Chrome, in the GDB console, type:
(gdb) target remote :4014-
This tells GDB to connect to a TCP port on localhost:4014
–the port that
+
This tells GDB to connect to a TCP port on localhost:4014
, the port that
Chrome is listening on. GDB will respond:
Remote debugging using :4014 @@ -237,8 +222,9 @@ Remote debugging using :4014
At this point, you can use the standard GDB commands to debug your NaCl module.
The most common commands you will use to debug are continue
, step
,
-next
, break
and backtrace
. See Debugging for more information about debugging a Native Client
-application.
next
, break
and backtrace
. See
+Debugging for more information about
+debugging a Native Client application.
naclsdk
utility