diff options
Diffstat (limited to 'documentation/migration-guides/migration-3.4.rst')
| -rw-r--r-- | documentation/migration-guides/migration-3.4.rst | 76 |
1 files changed, 76 insertions, 0 deletions
diff --git a/documentation/migration-guides/migration-3.4.rst b/documentation/migration-guides/migration-3.4.rst new file mode 100644 index 0000000000..6fa1ab20cb --- /dev/null +++ b/documentation/migration-guides/migration-3.4.rst | |||
| @@ -0,0 +1,76 @@ | |||
| 1 | Release 3.4 (honister) | ||
| 2 | ====================== | ||
| 3 | |||
| 4 | This section provides migration information for moving to the Yocto | ||
| 5 | Project 3.4 Release (codename "honister") from the prior release. | ||
| 6 | |||
| 7 | Override syntax changes | ||
| 8 | ----------------------- | ||
| 9 | |||
| 10 | This release requires changes to the metadata to indicate where overrides are | ||
| 11 | being used in variable key names. This is done with the ``:`` character replacing | ||
| 12 | the use of ``_`` previously. This means that an entry like:: | ||
| 13 | |||
| 14 | SRC_URI_qemux86 = "file://somefile" | ||
| 15 | |||
| 16 | becomes:: | ||
| 17 | |||
| 18 | SRC_URI:qemux86 = "file://somefile" | ||
| 19 | |||
| 20 | since ``qemux86`` is an override. This applies to any use of override syntax so:: | ||
| 21 | |||
| 22 | SRC_URI_append = " file://somefile" | ||
| 23 | SRC_URI_append_qemux86 = " file://somefile2" | ||
| 24 | SRC_URI_remove_qemux86-64 = " file://somefile3" | ||
| 25 | SRC_URI_prepend_qemuarm = "file://somefile4 " | ||
| 26 | FILES_${PN}-ptest = "${bindir}/xyz" | ||
| 27 | IMAGE_CMD_tar = "tar" | ||
| 28 | BASE_LIB_tune-cortexa76 = "lib" | ||
| 29 | SRCREV_pn-bash = "abc" | ||
| 30 | BB_TASK_NICE_LEVEL_task-testimage = '0' | ||
| 31 | |||
| 32 | becomes:: | ||
| 33 | |||
| 34 | SRC_URI:append = " file://somefile" | ||
| 35 | SRC_URI:append:qemux86 = " file://somefile2" | ||
| 36 | SRC_URI:remove:qemux86-64 = " file://somefile3" | ||
| 37 | SRC_URI:prepend:qemuarm = "file://somefile4 " | ||
| 38 | FILES:${PN}-ptest = "${bindir}/xyz" | ||
| 39 | IMAGE_CMD:tar = "tar" | ||
| 40 | BASE_LIB:tune-cortexa76 = "lib" | ||
| 41 | SRCREV:pn-bash = "abc" | ||
| 42 | BB_TASK_NICE_LEVEL:task-testimage = '0' | ||
| 43 | |||
| 44 | This also applies to | ||
| 45 | :ref:`variable queries to the datastore <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:functions for accessing datastore variables>`, | ||
| 46 | for example using ``getVar`` and similar so ``d.getVar("RDEPENDS_${PN}")`` | ||
| 47 | becomes ``d.getVar("RDEPENDS:${PN}")``. | ||
| 48 | |||
| 49 | Whilst some of these are fairly obvious such as :term:`MACHINE` and :term:`DISTRO` | ||
| 50 | overrides, some are less obvious, for example the packaging variables such as | ||
| 51 | :term:`RDEPENDS`, :term:`FILES` and so on taking package names (e.g. ``${PN}``, | ||
| 52 | ``${PN}-ptest``) as overrides. These overrides are not always in | ||
| 53 | :term:`OVERRIDES` but applied conditionally in specific contexts | ||
| 54 | such as packaging. ``task-<taskname>`` is another context specific override, the | ||
| 55 | context being specific tasks in that case. Tune overrides are another special | ||
| 56 | case where some code does use them as overrides but some does not. We plan to try | ||
| 57 | and make the tune code use overrides more consistently in the future. | ||
| 58 | |||
| 59 | To help with migration of layers there is a script in OE-Core. Once configured | ||
| 60 | with the overrides used by a layer, this can be run as:: | ||
| 61 | |||
| 62 | <oe-core>/scripts/contrib/convert-overrides.py <layerdir> | ||
| 63 | |||
| 64 | .. note:: | ||
| 65 | |||
| 66 | Please read the notes in the script as it isn't entirely automatic and it isn't | ||
| 67 | expected to handle every case. In particular, it needs to be told which overrides | ||
| 68 | the layer uses (usually machine and distro names/overrides) and the result should | ||
| 69 | be carefully checked since it can be a little enthusiastic and will convert | ||
| 70 | references to ``_append``, ``_remove`` and ``_prepend`` in function and variables names. | ||
| 71 | |||
| 72 | For reference, this conversion is important as it allows BitBake to know what is | ||
| 73 | an override and what is not. This should allow us to proceed with other syntax | ||
| 74 | improvements and simplifications for usability. It also means bitbake no longer | ||
| 75 | has to guess and maintain large lookup lists just in case ``functionname`` in | ||
| 76 | ``my_functionname`` is an override and this should improve efficiency. | ||
