sphinx: initial sphinx support

This commit is autogenerated pandoc to generate an inital set
of reST files based on DocBook XML files.

A .rst file is generated for each .xml files in all manuals with this
command:

cd <manual>
for i in *.xml; do \
  pandoc -f docbook -t rst --shift-heading-level-by=-1 \
  $i -o $(basename $i .xml).rst \
done

The conversion was done with: pandoc 2.9.2.1-91 (Arch Linux).

Also created an initial top level index file for each document, and
added all 'books' to the top leve index.rst file.

The YP manuals layout is organized as:

Book
  Chapter
    Section
      Section
        Section

Sphinx uses section headers to create the document structure.
ReStructuredText defines sections headers like that:

   To break longer text up into sections, you use section headers. These
   are a single line of text (one or more words) with adornment: an
   underline alone, or an underline and an overline together, in dashes
   "-----", equals "======", tildes "~~~~~~" or any of the
   non-alphanumeric characters = - ` : ' " ~ ^ _ * + # < > that you feel
   comfortable with. An underline-only adornment is distinct from an
   overline-and-underline adornment using the same character. The
   underline/overline must be at least as long as the title text. Be
   consistent, since all sections marked with the same adornment style
   are deemed to be at the same level:

Let's define the following convention when converting from Docbook:

Book                => overline ===   (Title)
  Chapter           => overline ***   (1.)
    Section         => ====           (1.1)
      Section       => ----           (1.1.1)
        Section     => ~~~~           (1.1.1.1)
          Section   => ^^^^           (1.1.1.1.1)

During the conversion with pandoc, we used --shift-heading-level=-1 to
convert most of DocBook headings automatically. However with this
setting, the Chapter header was removed, so I added it back
manually. Without this setting all headings were off by one, which was
more difficult to manually fix.

At least with this change, we now have the same TOC with Sphinx and
DocBook.

(From yocto-docs rev: 3c73d64a476d4423ee4c6808c685fa94d88d7df8)

Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 223 insertions, 0 deletions

diff --git a/documentation/sdk-manual/sdk-intro.rst b/documentation/sdk-manual/sdk-intro.rst
new file mode 100644
index 0000000000..f2641b7ade
--- /dev/null
+++ b/documentation/sdk-manual/sdk-intro.rst
@@ -0,0 +1,223 @@
+************
+Introduction
+************
+
+.. _sdk-manual-intro:
+
+Introduction
+============
+
+Welcome to the Yocto Project Application Development and the Extensible
+Software Development Kit (eSDK) manual. This manual provides information
+that explains how to use both the Yocto Project extensible and standard
+SDKs to develop applications and images.
+
+.. note::
+
+   Prior to the 2.0 Release of the Yocto Project, application
+   development was primarily accomplished through the use of the
+   Application Development Toolkit (ADT) and the availability of
+   stand-alone cross-development toolchains and other tools. With the
+   2.1 Release of the Yocto Project, application development has
+   transitioned to within a tool-rich extensible SDK and the more
+   traditional standard SDK.
+
+All SDKs consist of the following:
+
+-  *Cross-Development Toolchain*: This toolchain contains a compiler,
+   debugger, and various miscellaneous tools.
+
+-  *Libraries, Headers, and Symbols*: The libraries, headers, and
+   symbols are specific to the image (i.e. they match the image).
+
+-  *Environment Setup Script*: This ``*.sh`` file, once run, sets up the
+   cross-development environment by defining variables and preparing for
+   SDK use.
+
+Additionally, an extensible SDK has tools that allow you to easily add
+new applications and libraries to an image, modify the source of an
+existing component, test changes on the target hardware, and easily
+integrate an application into the `OpenEmbedded build
+system <&YOCTO_DOCS_REF_URL;#build-system-term>`__.
+
+You can use an SDK to independently develop and test code that is
+destined to run on some target machine. SDKs are completely
+self-contained. The binaries are linked against their own copy of
+``libc``, which results in no dependencies on the target system. To
+achieve this, the pointer to the dynamic loader is configured at install
+time since that path cannot be dynamically altered. This is the reason
+for a wrapper around the ``populate_sdk`` and ``populate_sdk_ext``
+archives.
+
+Another feature for the SDKs is that only one set of cross-compiler
+toolchain binaries are produced for any given architecture. This feature
+takes advantage of the fact that the target hardware can be passed to
+``gcc`` as a set of compiler options. Those options are set up by the
+environment script and contained in variables such as
+```CC`` <&YOCTO_DOCS_REF_URL;#var-CC>`__ and
+```LD`` <&YOCTO_DOCS_REF_URL;#var-LD>`__. This reduces the space needed
+for the tools. Understand, however, that every target still needs a
+sysroot because those binaries are target-specific.
+
+The SDK development environment consists of the following:
+
+-  The self-contained SDK, which is an architecture-specific
+   cross-toolchain and matching sysroots (target and native) all built
+   by the OpenEmbedded build system (e.g. the SDK). The toolchain and
+   sysroots are based on a `Metadata <&YOCTO_DOCS_REF_URL;#metadata>`__
+   configuration and extensions, which allows you to cross-develop on
+   the host machine for the target hardware. Additionally, the
+   extensible SDK contains the ``devtool`` functionality.
+
+-  The Quick EMUlator (QEMU), which lets you simulate target hardware.
+   QEMU is not literally part of the SDK. You must build and include
+   this emulator separately. However, QEMU plays an important role in
+   the development process that revolves around use of the SDK.
+
+In summary, the extensible and standard SDK share many features.
+However, the extensible SDK has powerful development tools to help you
+more quickly develop applications. Following is a table that summarizes
+the primary differences between the standard and extensible SDK types
+when considering which to build:
+
++-----------------------+-----------------------+-----------------------+
+| *Feature*             | *Standard SDK*        | *Extensible SDK*      |
++=======================+=======================+=======================+
+| Toolchain             | Yes                   | Yes\*                 |
++-----------------------+-----------------------+-----------------------+
+| Debugger              | Yes                   | Yes\*                 |
++-----------------------+-----------------------+-----------------------+
+| Size                  | 100+ MBytes           | 1+ GBytes (or 300+    |
+|                       |                       | MBytes for minimal    |
+|                       |                       | w/toolchain)          |
++-----------------------+-----------------------+-----------------------+
+| ``devtool``           | No                    | Yes                   |
++-----------------------+-----------------------+-----------------------+
+| Build Images          | No                    | Yes                   |
++-----------------------+-----------------------+-----------------------+
+| Updateable            | No                    | Yes                   |
++-----------------------+-----------------------+-----------------------+
+| Managed Sysroot*\*    | No                    | Yes                   |
++-----------------------+-----------------------+-----------------------+
+| Installed Packages    | No**\*                | Yes***\*              |
++-----------------------+-----------------------+-----------------------+
+| Construction          | Packages              | Shared State          |
++-----------------------+-----------------------+-----------------------+
+
+\* Extensible SDK contains the toolchain and debugger if
+```SDK_EXT_TYPE`` <&YOCTO_DOCS_REF_URL;#var-SDK_EXT_TYPE>`__ is "full"
+or
+```SDK_INCLUDE_TOOLCHAIN`` <&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_TOOLCHAIN>`__
+is "1", which is the default. \*\* Sysroot is managed through the use of
+``devtool``. Thus, it is less likely that you will corrupt your SDK
+sysroot when you try to add additional libraries. \**\* You can add
+runtime package management to the standard SDK but it is not supported
+by default. \***\* You must build and make the shared state available to
+extensible SDK users for "packages" you want to enable users to install.
+
+The Cross-Development Toolchain
+-------------------------------
+
+The `Cross-Development
+Toolchain <&YOCTO_DOCS_REF_URL;#cross-development-toolchain>`__ consists
+of a cross-compiler, cross-linker, and cross-debugger that are used to
+develop user-space applications for targeted hardware. Additionally, for
+an extensible SDK, the toolchain also has built-in ``devtool``
+functionality. This toolchain is created by running a SDK installer
+script or through a `Build
+Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ that is based on
+your metadata configuration or extension for your targeted device. The
+cross-toolchain works with a matching target sysroot.
+
+.. _sysroot:
+
+Sysroots
+--------
+
+The native and target sysroots contain needed headers and libraries for
+generating binaries that run on the target architecture. The target
+sysroot is based on the target root filesystem image that is built by
+the OpenEmbedded build system and uses the same metadata configuration
+used to build the cross-toolchain.
+
+The QEMU Emulator
+-----------------
+
+The QEMU emulator allows you to simulate your hardware while running
+your application or image. QEMU is not part of the SDK but is made
+available a number of different ways:
+
+-  If you have cloned the ``poky`` Git repository to create a `Source
+   Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ and you have
+   sourced the environment setup script, QEMU is installed and
+   automatically available.
+
+-  If you have downloaded a Yocto Project release and unpacked it to
+   create a Source Directory and you have sourced the environment setup
+   script, QEMU is installed and automatically available.
+
+-  If you have installed the cross-toolchain tarball and you have
+   sourced the toolchain's setup environment script, QEMU is also
+   installed and automatically available.
+
+SDK Development Model
+=====================
+
+Fundamentally, the SDK fits into the development process as follows: The
+SDK is installed on any machine and can be used to develop applications,
+images, and kernels. An SDK can even be used by a QA Engineer or Release
+Engineer. The fundamental concept is that the machine that has the SDK
+installed does not have to be associated with the machine that has the
+Yocto Project installed. A developer can independently compile and test
+an object on their machine and then, when the object is ready for
+integration into an image, they can simply make it available to the
+machine that has the Yocto Project. Once the object is available, the
+image can be rebuilt using the Yocto Project to produce the modified
+image.
+
+You just need to follow these general steps:
+
+1. *Install the SDK for your target hardware:* For information on how to
+   install the SDK, see the "`Installing the
+   SDK <#sdk-installing-the-sdk>`__" section.
+
+2. *Download or Build the Target Image:* The Yocto Project supports
+   several target architectures and has many pre-built kernel images and
+   root filesystem images.
+
+   If you are going to develop your application on hardware, go to the
+   ```machines`` <&YOCTO_MACHINES_DL_URL;>`__ download area and choose a
+   target machine area from which to download the kernel image and root
+   filesystem. This download area could have several files in it that
+   support development using actual hardware. For example, the area
+   might contain ``.hddimg`` files that combine the kernel image with
+   the filesystem, boot loaders, and so forth. Be sure to get the files
+   you need for your particular development process.
+
+   If you are going to develop your application and then run and test it
+   using the QEMU emulator, go to the
+   ```machines/qemu`` <&YOCTO_QEMU_DL_URL;>`__ download area. From this
+   area, go down into the directory for your target architecture (e.g.
+   ``qemux86_64`` for an Intel-based 64-bit architecture). Download the
+   kernel, root filesystem, and any other files you need for your
+   process.
+
+   .. note::
+
+      To use the root filesystem in QEMU, you need to extract it. See
+      the "
+      Extracting the Root Filesystem
+      " section for information on how to extract the root filesystem.
+
+3. *Develop and Test your Application:* At this point, you have the
+   tools to develop your application. If you need to separately install
+   and use the QEMU emulator, you can go to `QEMU Home
+   Page <http://wiki.qemu.org/Main_Page>`__ to download and learn about
+   the emulator. See the "`Using the Quick EMUlator
+   (QEMU) <&YOCTO_DOCS_DEV_URL;#dev-manual-qemu>`__" chapter in the
+   Yocto Project Development Tasks Manual for information on using QEMU
+   within the Yocto Project.
+
+The remainder of this manual describes how to use the extensible and
+standard SDKs. Information also exists in appendix form that describes
+how you can build, install, and modify an SDK.