migration-2.1.rst 18 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432
  1. Release 2.1 (krogoth)
  2. =====================
  3. This section provides migration information for moving to the Yocto
  4. Project 2.1 Release (codename "krogoth") from the prior release.
  5. .. _migration-2.1-variable-expansion-in-python-functions:
  6. Variable Expansion in Python Functions
  7. --------------------------------------
  8. Variable expressions, such as ``${VARNAME}`` no longer expand
  9. automatically within Python functions. Suppressing expansion was done to
  10. allow Python functions to construct shell scripts or other code for
  11. situations in which you do not want such expressions expanded. For any
  12. existing code that relies on these expansions, you need to change the
  13. expansions to expand the value of individual variables through
  14. ``d.getVar()``. To alternatively expand more complex expressions, use
  15. ``d.expand()``.
  16. .. _migration-2.1-overrides-must-now-be-lower-case:
  17. Overrides Must Now be Lower-Case
  18. --------------------------------
  19. The convention for overrides has always been for them to be lower-case
  20. characters. This practice is now a requirement as BitBake's datastore
  21. now assumes lower-case characters in order to give a slight performance
  22. boost during parsing. In practical terms, this requirement means that
  23. anything that ends up in :term:`OVERRIDES` must now
  24. appear in lower-case characters (e.g. values for :term:`MACHINE`,
  25. :term:`TARGET_ARCH`, :term:`DISTRO`, and also recipe names if
  26. ``_pn-``\ recipename overrides are to be effective).
  27. .. _migration-2.1-expand-parameter-to-getvar-and-getvarflag-now-mandatory:
  28. Expand Parameter to ``getVar()`` and ``getVarFlag()`` is Now Mandatory
  29. ----------------------------------------------------------------------
  30. The expand parameter to ``getVar()`` and ``getVarFlag()`` previously
  31. defaulted to False if not specified. Now, however, no default exists so
  32. one must be specified. You must change any ``getVar()`` calls that do
  33. not specify the final expand parameter to calls that do specify the
  34. parameter. You can run the following ``sed`` command at the base of a
  35. layer to make this change::
  36. sed -e 's:\(\.getVar([^,()]*\)):\1, False):g' -i `grep -ril getVar *`
  37. sed -e 's:\(\.getVarFlag([^,()]*,[^,()]*\)):\1, False):g' -i `grep -ril getVarFlag *`
  38. .. note::
  39. The reason for this change is that it prepares the way for changing
  40. the default to True in a future Yocto Project release. This future
  41. change is a much more sensible default than False. However, the
  42. change needs to be made gradually as a sudden change of the default
  43. would potentially cause side-effects that would be difficult to
  44. detect.
  45. .. _migration-2.1-makefile-environment-changes:
  46. Makefile Environment Changes
  47. ----------------------------
  48. :term:`EXTRA_OEMAKE` now defaults to "" instead of
  49. "-e MAKEFLAGS=". Setting :term:`EXTRA_OEMAKE` to "-e MAKEFLAGS=" by default
  50. was a historical accident that has required many classes (e.g.
  51. :ref:`autotools <ref-classes-autotools>`, ``module``) and recipes to override this default in order
  52. to work with sensible build systems. When upgrading to the release, you
  53. must edit any recipe that relies upon this old default by either setting
  54. :term:`EXTRA_OEMAKE` back to "-e MAKEFLAGS=" or by explicitly setting any
  55. required variable value overrides using :term:`EXTRA_OEMAKE`, which is
  56. typically only needed when a Makefile sets a default value for a
  57. variable that is inappropriate for cross-compilation using the "="
  58. operator rather than the "?=" operator.
  59. .. _migration-2.1-libexecdir-reverted-to-prefix-libexec:
  60. ``libexecdir`` Reverted to ``${prefix}/libexec``
  61. ------------------------------------------------
  62. The use of ``${libdir}/${BPN}`` as ``libexecdir`` is different as
  63. compared to all other mainstream distributions, which either uses
  64. ``${prefix}/libexec`` or ``${libdir}``. The use is also contrary to the
  65. GNU Coding Standards (i.e.
  66. https://www.gnu.org/prep/standards/html_node/Directory-Variables.html)
  67. that suggest ``${prefix}/libexec`` and also notes that any
  68. package-specific nesting should be done by the package itself. Finally,
  69. having ``libexecdir`` change between recipes makes it very difficult for
  70. different recipes to invoke binaries that have been installed into
  71. ``libexecdir``. The Filesystem Hierarchy Standard (i.e.
  72. https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html) now
  73. recognizes the use of ``${prefix}/libexec/``, giving distributions the
  74. choice between ``${prefix}/lib`` or ``${prefix}/libexec`` without
  75. breaking FHS.
  76. .. _migration-2.1-ac-cv-sizeof-off-t-no-longer-cached-in-site-files:
  77. ``ac_cv_sizeof_off_t`` is No Longer Cached in Site Files
  78. --------------------------------------------------------
  79. For recipes inheriting the :ref:`autotools <ref-classes-autotools>`
  80. class, ``ac_cv_sizeof_off_t`` is no longer cached in the site files for
  81. ``autoconf``. The reason for this change is because the
  82. ``ac_cv_sizeof_off_t`` value is not necessarily static per architecture
  83. as was previously assumed. Rather, the value changes based on whether
  84. large file support is enabled. For most software that uses ``autoconf``,
  85. this change should not be a problem. However, if you have a recipe that
  86. bypasses the standard :ref:`ref-tasks-configure` task
  87. from the :ref:`autotools <ref-classes-autotools>` class and the software the recipe is building
  88. uses a very old version of ``autoconf``, the recipe might be incapable
  89. of determining the correct size of ``off_t`` during :ref:`ref-tasks-configure`.
  90. The best course of action is to patch the software as necessary to allow
  91. the default implementation from the :ref:`autotools <ref-classes-autotools>` class to work such
  92. that ``autoreconf`` succeeds and produces a working configure script,
  93. and to remove the overridden :ref:`ref-tasks-configure` task such that the default
  94. implementation does get used.
  95. .. _migration-2.1-image-generation-split-out-from-filesystem-generation:
  96. Image Generation is Now Split Out from Filesystem Generation
  97. ------------------------------------------------------------
  98. Previously, for image recipes the :ref:`ref-tasks-rootfs`
  99. task assembled the filesystem and then from that filesystem generated
  100. images. With this Yocto Project release, image generation is split into
  101. separate :ref:`ref-tasks-image` tasks for clarity both in
  102. operation and in the code.
  103. For most cases, this change does not present any problems. However, if
  104. you have made customizations that directly modify the :ref:`ref-tasks-rootfs` task
  105. or that mention :ref:`ref-tasks-rootfs`, you might need to update those changes.
  106. In particular, if you had added any tasks after :ref:`ref-tasks-rootfs`, you
  107. should make edits so that those tasks are after the
  108. :ref:`ref-tasks-image-complete` task rather than
  109. after :ref:`ref-tasks-rootfs` so that your added tasks run at the correct
  110. time.
  111. A minor part of this restructuring is that the post-processing
  112. definitions and functions have been moved from the
  113. :ref:`image <ref-classes-image>` class to the
  114. :ref:`rootfs-postcommands <ref-classes-rootfs*>` class. Functionally,
  115. however, they remain unchanged.
  116. .. _migration-2.1-removed-recipes:
  117. Removed Recipes
  118. ---------------
  119. The following recipes have been removed in the 2.1 release:
  120. - ``gcc`` version 4.8: Versions 4.9 and 5.3 remain.
  121. - ``qt4``: All support for Qt 4.x has been moved out to a separate
  122. ``meta-qt4`` layer because Qt 4 is no longer supported upstream.
  123. - ``x11vnc``: Moved to the ``meta-oe`` layer.
  124. - ``linux-yocto-3.14``: No longer supported.
  125. - ``linux-yocto-3.19``: No longer supported.
  126. - ``libjpeg``: Replaced by the ``libjpeg-turbo`` recipe.
  127. - ``pth``: Became obsolete.
  128. - ``liboil``: Recipe is no longer needed and has been moved to the
  129. ``meta-multimedia`` layer.
  130. - ``gtk-theme-torturer``: Recipe is no longer needed and has been moved
  131. to the ``meta-gnome`` layer.
  132. - ``gnome-mime-data``: Recipe is no longer needed and has been moved to
  133. the ``meta-gnome`` layer.
  134. - ``udev``: Replaced by the ``eudev`` recipe for compatibility when
  135. using ``sysvinit`` with newer kernels.
  136. - ``python-pygtk``: Recipe became obsolete.
  137. - ``adt-installer``: Recipe became obsolete. See the
  138. ":ref:`migration-guides/migration-2.1:adt removed`" section for more information.
  139. .. _migration-2.1-class-changes:
  140. Class Changes
  141. -------------
  142. The following classes have changed:
  143. - ``autotools_stage``: Removed because the
  144. :ref:`autotools <ref-classes-autotools>` class now provides its
  145. functionality. Recipes that inherited from ``autotools_stage`` should
  146. now inherit from :ref:`autotools <ref-classes-autotools>` instead.
  147. - ``boot-directdisk``: Merged into the ``image-vm`` class. The
  148. ``boot-directdisk`` class was rarely directly used. Consequently,
  149. this change should not cause any issues.
  150. - ``bootimg``: Merged into the
  151. :ref:`image-live <ref-classes-image-live>` class. The ``bootimg``
  152. class was rarely directly used. Consequently, this change should not
  153. cause any issues.
  154. - ``packageinfo``: Removed due to its limited use by the Hob UI, which
  155. has itself been removed.
  156. .. _migration-2.1-build-system-ui-changes:
  157. Build System User Interface Changes
  158. -----------------------------------
  159. The following changes have been made to the build system user interface:
  160. - *Hob GTK+-based UI*: Removed because it is unmaintained and based on
  161. the outdated GTK+ 2 library. The Toaster web-based UI is much more
  162. capable and is actively maintained. See the
  163. ":ref:`toaster-manual/setup-and-use:using the toaster web interface`"
  164. section in the Toaster User Manual for more information on this
  165. interface.
  166. - *"puccho" BitBake UI*: Removed because is unmaintained and no longer
  167. useful.
  168. .. _migration-2.1-adt-removed:
  169. ADT Removed
  170. -----------
  171. The Application Development Toolkit (ADT) has been removed because its
  172. functionality almost completely overlapped with the :ref:`standard
  173. SDK <sdk-manual/using:using the standard sdk>` and the
  174. :ref:`extensible SDK <sdk-manual/extensible:using the extensible sdk>`. For
  175. information on these SDKs and how to build and use them, see the
  176. :doc:`/sdk-manual/index` manual.
  177. .. note::
  178. The Yocto Project Eclipse IDE Plug-in is still supported and is not
  179. affected by this change.
  180. .. _migration-2.1-poky-reference-distribution-changes:
  181. Poky Reference Distribution Changes
  182. -----------------------------------
  183. The following changes have been made for the Poky distribution:
  184. - The ``meta-yocto`` layer has been renamed to ``meta-poky`` to better
  185. match its purpose, which is to provide the Poky reference
  186. distribution. The ``meta-yocto-bsp`` layer retains its original name
  187. since it provides reference machines for the Yocto Project and it is
  188. otherwise unrelated to Poky. References to ``meta-yocto`` in your
  189. ``conf/bblayers.conf`` should automatically be updated, so you should
  190. not need to change anything unless you are relying on this naming
  191. elsewhere.
  192. - The :ref:`uninative <ref-classes-uninative>` class is now enabled
  193. by default in Poky. This class attempts to isolate the build system
  194. from the host distribution's C library and makes re-use of native
  195. shared state artifacts across different host distributions practical.
  196. With this class enabled, a tarball containing a pre-built C library
  197. is downloaded at the start of the build.
  198. The :ref:`uninative <ref-classes-uninative>` class is enabled through the
  199. ``meta/conf/distro/include/yocto-uninative.inc`` file, which for
  200. those not using the Poky distribution, can include to easily enable
  201. the same functionality.
  202. Alternatively, if you wish to build your own ``uninative`` tarball,
  203. you can do so by building the ``uninative-tarball`` recipe, making it
  204. available to your build machines (e.g. over HTTP/HTTPS) and setting a
  205. similar configuration as the one set by ``yocto-uninative.inc``.
  206. - Static library generation, for most cases, is now disabled by default
  207. in the Poky distribution. Disabling this generation saves some build
  208. time as well as the size used for build output artifacts.
  209. Disabling this library generation is accomplished through a
  210. ``meta/conf/distro/include/no-static-libs.inc``, which for those not
  211. using the Poky distribution can easily include to enable the same
  212. functionality.
  213. Any recipe that needs to opt-out of having the ``--disable-static``
  214. option specified on the configure command line either because it is
  215. not a supported option for the configure script or because static
  216. libraries are needed should set the following variable::
  217. DISABLE_STATIC = ""
  218. - The separate ``poky-tiny`` distribution now uses the musl C library
  219. instead of a heavily pared down ``glibc``. Using musl results in a
  220. smaller distribution and facilitates much greater maintainability
  221. because musl is designed to have a small footprint.
  222. If you have used ``poky-tiny`` and have customized the ``glibc``
  223. configuration you will need to redo those customizations with musl
  224. when upgrading to the new release.
  225. .. _migration-2.1-packaging-changes:
  226. Packaging Changes
  227. -----------------
  228. The following changes have been made to packaging:
  229. - The ``runuser`` and ``mountpoint`` binaries, which were previously in
  230. the main ``util-linux`` package, have been split out into the
  231. ``util-linux-runuser`` and ``util-linux-mountpoint`` packages,
  232. respectively.
  233. - The ``python-elementtree`` package has been merged into the
  234. ``python-xml`` package.
  235. .. _migration-2.1-tuning-file-changes:
  236. Tuning File Changes
  237. -------------------
  238. The following changes have been made to the tuning files:
  239. - The "no-thumb-interwork" tuning feature has been dropped from the ARM
  240. tune include files. Because interworking is required for ARM EABI,
  241. attempting to disable it through a tuning feature no longer makes
  242. sense.
  243. .. note::
  244. Support for ARM OABI was deprecated in gcc 4.7.
  245. - The ``tune-cortexm*.inc`` and ``tune-cortexr4.inc`` files have been
  246. removed because they are poorly tested. Until the OpenEmbedded build
  247. system officially gains support for CPUs without an MMU, these tuning
  248. files would probably be better maintained in a separate layer if
  249. needed.
  250. .. _migration-2.1-supporting-gobject-introspection:
  251. Supporting GObject Introspection
  252. --------------------------------
  253. This release supports generation of GLib Introspective Repository (GIR)
  254. files through GObject introspection, which is the standard mechanism for
  255. accessing GObject-based software from runtime environments. You can
  256. enable, disable, and test the generation of this data. See the
  257. ":ref:`dev-manual/gobject-introspection:enabling gobject introspection support`"
  258. section in the Yocto Project Development Tasks Manual for more
  259. information.
  260. .. _migration-2.1-miscellaneous-changes:
  261. Miscellaneous Changes
  262. ---------------------
  263. These additional changes exist:
  264. - The minimum Git version has been increased to 1.8.3.1. If your host
  265. distribution does not provide a sufficiently recent version, you can
  266. install the buildtools, which will provide it. See the
  267. :ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`
  268. section for more information on the buildtools tarball.
  269. - The buggy and incomplete support for the RPM version 4 package
  270. manager has been removed. The well-tested and maintained support for
  271. RPM version 5 remains.
  272. - Previously, the following list of packages were removed if
  273. package-management was not in
  274. :term:`IMAGE_FEATURES`, regardless of any
  275. dependencies::
  276. update-rc.d
  277. base-passwd
  278. shadow
  279. update-alternatives
  280. run-postinsts
  281. With the Yocto Project 2.1 release, these packages are
  282. only removed if "read-only-rootfs" is in :term:`IMAGE_FEATURES`, since
  283. they might still be needed for a read-write image even in the absence
  284. of a package manager (e.g. if users need to be added, modified, or
  285. removed at runtime).
  286. - The
  287. :ref:`devtool modify <sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`
  288. command now defaults to extracting the source since that is most
  289. commonly expected. The ``-x`` or ``--extract`` options are now no-ops. If
  290. you wish to provide your own existing source tree, you will now need
  291. to specify either the ``-n`` or ``--no-extract`` options when running
  292. ``devtool modify``.
  293. - If the formfactor for a machine is either not supplied or does not
  294. specify whether a keyboard is attached, then the default is to assume
  295. a keyboard is attached rather than assume no keyboard. This change
  296. primarily affects the Sato UI.
  297. - The ``.debug`` directory packaging is now automatic. If your recipe
  298. builds software that installs binaries into directories other than
  299. the standard ones, you no longer need to take care of setting
  300. ``FILES_${PN}-dbg`` to pick up the resulting ``.debug`` directories
  301. as these directories are automatically found and added.
  302. - Inaccurate disk and CPU percentage data has been dropped from
  303. :ref:`buildstats <ref-classes-buildstats>` output. This data has been replaced with
  304. ``getrusage()`` data and corrected IO statistics. You will probably
  305. need to update any custom code that reads the :ref:`buildstats <ref-classes-buildstats>` data.
  306. - The ``meta/conf/distro/include/package_regex.inc`` is now deprecated.
  307. The contents of this file have been moved to individual recipes.
  308. .. note::
  309. Because this file will likely be removed in a future Yocto Project
  310. release, it is suggested that you remove any references to the
  311. file that might be in your configuration.
  312. - The ``v86d/uvesafb`` has been removed from the ``genericx86`` and
  313. ``genericx86-64`` reference machines, which are provided by the
  314. ``meta-yocto-bsp`` layer. Most modern x86 boards do not rely on this
  315. file and it only adds kernel error messages during startup. If you do
  316. still need to support ``uvesafb``, you can simply add ``v86d`` to
  317. your image.
  318. - Build sysroot paths are now removed from debug symbol files. Removing
  319. these paths means that remote GDB using an unstripped build system
  320. sysroot will no longer work (although this was never documented to
  321. work). The supported method to accomplish something similar is to set
  322. ``IMAGE_GEN_DEBUGFS`` to "1", which will generate a companion debug
  323. image containing unstripped binaries and associated debug sources
  324. alongside the image.