sdk-intro.rst 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225
  1. .. SPDX-License-Identifier: CC-BY-2.0-UK
  2. ************
  3. Introduction
  4. ************
  5. .. _sdk-manual-intro:
  6. Introduction
  7. ============
  8. Welcome to the Yocto Project Application Development and the Extensible
  9. Software Development Kit (eSDK) manual. This manual provides information
  10. that explains how to use both the Yocto Project extensible and standard
  11. SDKs to develop applications and images.
  12. .. note::
  13. Prior to the 2.0 Release of the Yocto Project, application
  14. development was primarily accomplished through the use of the
  15. Application Development Toolkit (ADT) and the availability of
  16. stand-alone cross-development toolchains and other tools. With the
  17. 2.1 Release of the Yocto Project, application development has
  18. transitioned to within a tool-rich extensible SDK and the more
  19. traditional standard SDK.
  20. All SDKs consist of the following:
  21. - *Cross-Development Toolchain*: This toolchain contains a compiler,
  22. debugger, and various miscellaneous tools.
  23. - *Libraries, Headers, and Symbols*: The libraries, headers, and
  24. symbols are specific to the image (i.e. they match the image).
  25. - *Environment Setup Script*: This ``*.sh`` file, once run, sets up the
  26. cross-development environment by defining variables and preparing for
  27. SDK use.
  28. Additionally, an extensible SDK has tools that allow you to easily add
  29. new applications and libraries to an image, modify the source of an
  30. existing component, test changes on the target hardware, and easily
  31. integrate an application into the `OpenEmbedded build
  32. system <&YOCTO_DOCS_REF_URL;#build-system-term>`__.
  33. You can use an SDK to independently develop and test code that is
  34. destined to run on some target machine. SDKs are completely
  35. self-contained. The binaries are linked against their own copy of
  36. ``libc``, which results in no dependencies on the target system. To
  37. achieve this, the pointer to the dynamic loader is configured at install
  38. time since that path cannot be dynamically altered. This is the reason
  39. for a wrapper around the ``populate_sdk`` and ``populate_sdk_ext``
  40. archives.
  41. Another feature for the SDKs is that only one set of cross-compiler
  42. toolchain binaries are produced for any given architecture. This feature
  43. takes advantage of the fact that the target hardware can be passed to
  44. ``gcc`` as a set of compiler options. Those options are set up by the
  45. environment script and contained in variables such as
  46. :term:`CC` and
  47. :term:`LD`. This reduces the space needed
  48. for the tools. Understand, however, that every target still needs a
  49. sysroot because those binaries are target-specific.
  50. The SDK development environment consists of the following:
  51. - The self-contained SDK, which is an architecture-specific
  52. cross-toolchain and matching sysroots (target and native) all built
  53. by the OpenEmbedded build system (e.g. the SDK). The toolchain and
  54. sysroots are based on a :term:`Metadata`
  55. configuration and extensions, which allows you to cross-develop on
  56. the host machine for the target hardware. Additionally, the
  57. extensible SDK contains the ``devtool`` functionality.
  58. - The Quick EMUlator (QEMU), which lets you simulate target hardware.
  59. QEMU is not literally part of the SDK. You must build and include
  60. this emulator separately. However, QEMU plays an important role in
  61. the development process that revolves around use of the SDK.
  62. In summary, the extensible and standard SDK share many features.
  63. However, the extensible SDK has powerful development tools to help you
  64. more quickly develop applications. Following is a table that summarizes
  65. the primary differences between the standard and extensible SDK types
  66. when considering which to build:
  67. +-----------------------+-----------------------+-----------------------+
  68. | *Feature* | *Standard SDK* | *Extensible SDK* |
  69. +=======================+=======================+=======================+
  70. | Toolchain | Yes | Yes\* |
  71. +-----------------------+-----------------------+-----------------------+
  72. | Debugger | Yes | Yes\* |
  73. +-----------------------+-----------------------+-----------------------+
  74. | Size | 100+ MBytes | 1+ GBytes (or 300+ |
  75. | | | MBytes for minimal |
  76. | | | w/toolchain) |
  77. +-----------------------+-----------------------+-----------------------+
  78. | ``devtool`` | No | Yes |
  79. +-----------------------+-----------------------+-----------------------+
  80. | Build Images | No | Yes |
  81. +-----------------------+-----------------------+-----------------------+
  82. | Updateable | No | Yes |
  83. +-----------------------+-----------------------+-----------------------+
  84. | Managed Sysroot*\* | No | Yes |
  85. +-----------------------+-----------------------+-----------------------+
  86. | Installed Packages | No**\* | Yes***\* |
  87. +-----------------------+-----------------------+-----------------------+
  88. | Construction | Packages | Shared State |
  89. +-----------------------+-----------------------+-----------------------+
  90. \* Extensible SDK contains the toolchain and debugger if
  91. :term:`SDK_EXT_TYPE` is "full"
  92. or
  93. :term:`SDK_INCLUDE_TOOLCHAIN`
  94. is "1", which is the default. \*\* Sysroot is managed through the use of
  95. ``devtool``. Thus, it is less likely that you will corrupt your SDK
  96. sysroot when you try to add additional libraries. \**\* You can add
  97. runtime package management to the standard SDK but it is not supported
  98. by default. \***\* You must build and make the shared state available to
  99. extensible SDK users for "packages" you want to enable users to install.
  100. The Cross-Development Toolchain
  101. -------------------------------
  102. The `Cross-Development
  103. Toolchain <&YOCTO_DOCS_REF_URL;#cross-development-toolchain>`__ consists
  104. of a cross-compiler, cross-linker, and cross-debugger that are used to
  105. develop user-space applications for targeted hardware. Additionally, for
  106. an extensible SDK, the toolchain also has built-in ``devtool``
  107. functionality. This toolchain is created by running a SDK installer
  108. script or through a `Build
  109. Directory <&YOCTO_DOCS_REF_URL;#build-directory>`__ that is based on
  110. your metadata configuration or extension for your targeted device. The
  111. cross-toolchain works with a matching target sysroot.
  112. .. _sysroot:
  113. Sysroots
  114. --------
  115. The native and target sysroots contain needed headers and libraries for
  116. generating binaries that run on the target architecture. The target
  117. sysroot is based on the target root filesystem image that is built by
  118. the OpenEmbedded build system and uses the same metadata configuration
  119. used to build the cross-toolchain.
  120. The QEMU Emulator
  121. -----------------
  122. The QEMU emulator allows you to simulate your hardware while running
  123. your application or image. QEMU is not part of the SDK but is made
  124. available a number of different ways:
  125. - If you have cloned the ``poky`` Git repository to create a `Source
  126. Directory <&YOCTO_DOCS_REF_URL;#source-directory>`__ and you have
  127. sourced the environment setup script, QEMU is installed and
  128. automatically available.
  129. - If you have downloaded a Yocto Project release and unpacked it to
  130. create a Source Directory and you have sourced the environment setup
  131. script, QEMU is installed and automatically available.
  132. - If you have installed the cross-toolchain tarball and you have
  133. sourced the toolchain's setup environment script, QEMU is also
  134. installed and automatically available.
  135. SDK Development Model
  136. =====================
  137. Fundamentally, the SDK fits into the development process as follows: The
  138. SDK is installed on any machine and can be used to develop applications,
  139. images, and kernels. An SDK can even be used by a QA Engineer or Release
  140. Engineer. The fundamental concept is that the machine that has the SDK
  141. installed does not have to be associated with the machine that has the
  142. Yocto Project installed. A developer can independently compile and test
  143. an object on their machine and then, when the object is ready for
  144. integration into an image, they can simply make it available to the
  145. machine that has the Yocto Project. Once the object is available, the
  146. image can be rebuilt using the Yocto Project to produce the modified
  147. image.
  148. You just need to follow these general steps:
  149. 1. *Install the SDK for your target hardware:* For information on how to
  150. install the SDK, see the "`Installing the
  151. SDK <#sdk-installing-the-sdk>`__" section.
  152. 2. *Download or Build the Target Image:* The Yocto Project supports
  153. several target architectures and has many pre-built kernel images and
  154. root filesystem images.
  155. If you are going to develop your application on hardware, go to the
  156. ```machines`` <&YOCTO_MACHINES_DL_URL;>`__ download area and choose a
  157. target machine area from which to download the kernel image and root
  158. filesystem. This download area could have several files in it that
  159. support development using actual hardware. For example, the area
  160. might contain ``.hddimg`` files that combine the kernel image with
  161. the filesystem, boot loaders, and so forth. Be sure to get the files
  162. you need for your particular development process.
  163. If you are going to develop your application and then run and test it
  164. using the QEMU emulator, go to the
  165. ```machines/qemu`` <&YOCTO_QEMU_DL_URL;>`__ download area. From this
  166. area, go down into the directory for your target architecture (e.g.
  167. ``qemux86_64`` for an Intel-based 64-bit architecture). Download the
  168. kernel, root filesystem, and any other files you need for your
  169. process.
  170. .. note::
  171. To use the root filesystem in QEMU, you need to extract it. See
  172. the "
  173. Extracting the Root Filesystem
  174. " section for information on how to extract the root filesystem.
  175. 3. *Develop and Test your Application:* At this point, you have the
  176. tools to develop your application. If you need to separately install
  177. and use the QEMU emulator, you can go to `QEMU Home
  178. Page <http://wiki.qemu.org/Main_Page>`__ to download and learn about
  179. the emulator. See the "`Using the Quick EMUlator
  180. (QEMU) <&YOCTO_DOCS_DEV_URL;#dev-manual-qemu>`__" chapter in the
  181. Yocto Project Development Tasks Manual for information on using QEMU
  182. within the Yocto Project.
  183. The remainder of this manual describes how to use the extensible and
  184. standard SDKs. Information also exists in appendix form that describes
  185. how you can build, install, and modify an SDK.