summaryrefslogtreecommitdiffstats
path: root/documentation
diff options
context:
space:
mode:
Diffstat (limited to 'documentation')
-rw-r--r--documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst14
-rw-r--r--documentation/overview-manual/overview-manual-concepts.rst79
-rw-r--r--documentation/transitioning-to-a-custom-environment.rst8
3 files changed, 35 insertions, 66 deletions
diff --git a/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst b/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
index 6eabf3b806..7e24b9e685 100644
--- a/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
+++ b/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
@@ -131,7 +131,7 @@ Move to the ``poky`` directory and take a look at the tags:
131 yocto_1.5_M5.rc8 131 yocto_1.5_M5.rc8
132 132
133For this example, check out the branch based on the 133For this example, check out the branch based on the
134&DISTRO_REL_TAG; release: 134``&DISTRO_REL_TAG;`` release:
135 135
136.. code-block:: shell 136.. code-block:: shell
137 137
@@ -139,8 +139,8 @@ For this example, check out the branch based on the
139 Switched to a new branch 'my-&DISTRO_REL_TAG;' 139 Switched to a new branch 'my-&DISTRO_REL_TAG;'
140 140
141The previous Git checkout command creates a local branch named 141The previous Git checkout command creates a local branch named
142my-&DISTRO_REL_TAG;. The files available to you in that branch exactly 142``my-&DISTRO_REL_TAG;``. The files available to you in that branch exactly
143match the repository's files in the "&DISTRO_NAME_NO_CAP;" development 143match the repository's files in the ``&DISTRO_NAME_NO_CAP;`` development
144branch at the time of the Yocto Project &DISTRO_REL_TAG; release. 144branch at the time of the Yocto Project &DISTRO_REL_TAG; release.
145 145
146For more options and information about accessing Yocto Project related 146For more options and information about accessing Yocto Project related
@@ -317,7 +317,7 @@ Follow these steps to add a hardware layer:
317#. **Change the Configuration to Build for a Specific Machine:** The 317#. **Change the Configuration to Build for a Specific Machine:** The
318 :term:`MACHINE` variable in the 318 :term:`MACHINE` variable in the
319 ``local.conf`` file specifies the machine for the build. For this 319 ``local.conf`` file specifies the machine for the build. For this
320 example, set the ``MACHINE`` variable to "cyclone5". These 320 example, set the ``MACHINE`` variable to ``cyclone5``. These
321 configurations are used: 321 configurations are used:
322 https://github.com/kraj/meta-altera/blob/master/conf/machine/cyclone5.conf. 322 https://github.com/kraj/meta-altera/blob/master/conf/machine/cyclone5.conf.
323 323
@@ -351,13 +351,13 @@ Follow these steps to add a hardware layer:
351 351
352Completing these steps has added the ``meta-altera`` layer to your Yocto 352Completing these steps has added the ``meta-altera`` layer to your Yocto
353Project development environment and configured it to build for the 353Project development environment and configured it to build for the
354"cyclone5" machine. 354``cyclone5`` machine.
355 355
356.. note:: 356.. note::
357 357
358 The previous steps are for demonstration purposes only. If you were 358 The previous steps are for demonstration purposes only. If you were
359 to attempt to build an image for the "cyclone5" machine, you should 359 to attempt to build an image for the ``cyclone5`` machine, you should
360 read the Altera README. 360 read the Altera ``README``.
361 361
362Creating Your Own General Layer 362Creating Your Own General Layer
363=============================== 363===============================
diff --git a/documentation/overview-manual/overview-manual-concepts.rst b/documentation/overview-manual/overview-manual-concepts.rst
index 9bd02a7001..08d640a5bc 100644
--- a/documentation/overview-manual/overview-manual-concepts.rst
+++ b/documentation/overview-manual/overview-manual-concepts.rst
@@ -278,7 +278,7 @@ development environment.
278 The 278 The
279 scripts/oe-setup-builddir 279 scripts/oe-setup-builddir
280 script uses the 280 script uses the
281 $TEMPLATECONF 281 ``$TEMPLATECONF``
282 variable to determine which sample configuration files to locate. 282 variable to determine which sample configuration files to locate.
283 283
284The ``local.conf`` file provides many basic variables that define a 284The ``local.conf`` file provides many basic variables that define a
@@ -620,8 +620,7 @@ module.
620 For information on how to have the OpenEmbedded build system generate 620 For information on how to have the OpenEmbedded build system generate
621 tarballs for Git repositories and place them in the 621 tarballs for Git repositories and place them in the
622 DL_DIR 622 DL_DIR
623 directory, see the 623 directory, see the :term:`BB_GENERATE_MIRROR_TARBALLS`
624 BB_GENERATE_MIRROR_TARBALLS
625 variable in the Yocto Project Reference Manual. 624 variable in the Yocto Project Reference Manual.
626 625
627When fetching a repository, BitBake uses the 626When fetching a repository, BitBake uses the
@@ -1243,9 +1242,9 @@ usually made available in the form of a shared state (sstate) cache.
1243.. note:: 1242.. note::
1244 1243
1245 For information on variables affecting sstate, see the 1244 For information on variables affecting sstate, see the
1246 SSTATE_DIR 1245 :term:`SSTATE_DIR`
1247 and 1246 and
1248 SSTATE_MIRRORS 1247 :term:`SSTATE_MIRRORS`
1249 variables. 1248 variables.
1250 1249
1251The idea of a setscene task (i.e ``do_``\ taskname\ ``_setscene``) is a 1250The idea of a setscene task (i.e ``do_``\ taskname\ ``_setscene``) is a
@@ -1916,25 +1915,15 @@ The following list explains the previous example:
1916 1915
1917 .. note:: 1916 .. note::
1918 1917
1919 If 1918 If ``do_deploy`` is not already in the shared state cache or if its input
1920 do_deploy 1919 checksum (signature) has changed from when the output was cached, the task
1921 is not already in the shared state cache or if its input checksum 1920 runs to populate the shared state cache, after which the contents of the
1922 (signature) has changed from when the output was cached, the task 1921 shared state cache is copied to ${:term:`DEPLOY_DIR_IMAGE`}. If
1923 runs to populate the shared state cache, after which the contents 1922 ``do_deploy`` is in the shared state cache and its signature indicates
1924 of the shared state cache is copied to 1923 that the cached output is still valid (i.e. if no relevant task inputs
1925 ${DEPLOY_DIR_IMAGE} 1924 have changed), then the contents of the shared state cache copies
1926 . If 1925 directly to ${``DEPLOY_DIR_IMAGE``} by the ``do_deploy_setscene`` task
1927 do_deploy 1926 instead, skipping the ``do_deploy`` task.
1928 is in the shared state cache and its signature indicates that the
1929 cached output is still valid (i.e. if no relevant task inputs have
1930 changed), then the contents of the shared state cache copies
1931 directly to
1932 ${DEPLOY_DIR_IMAGE}
1933 by the
1934 do_deploy_setscene
1935 task instead, skipping the
1936 do_deploy
1937 task.
1938 1927
1939- The following task definition is glue logic needed to make the 1928- The following task definition is glue logic needed to make the
1940 previous settings effective: 1929 previous settings effective:
@@ -1961,18 +1950,9 @@ The following list explains the previous example:
1961 1950
1962 .. note:: 1951 .. note::
1963 1952
1964 In cases where 1953 In cases where ``sstate-inputdirs`` and ``sstate-outputdirs`` would be
1965 sstate-inputdirs 1954 the same, you can use ``sstate-plaindirs``. For example, to preserve the
1966 and 1955 ${:term:`PKGD`} and ${:term:`PKGDEST`} output from the ``do_package``
1967 sstate-outputdirs
1968 would be the same, you can use
1969 sstate-plaindirs
1970 . For example, to preserve the
1971 ${PKGD}
1972 and
1973 ${PKGDEST}
1974 output from the
1975 do_package
1976 task, use the following: 1956 task, use the following:
1977 :: 1957 ::
1978 1958
@@ -2016,14 +1996,11 @@ shared state files. Here is an example:
2016 1996
2017.. note:: 1997.. note::
2018 1998
2019 The shared state directory ( 1999 The shared state directory (``SSTATE_DIR``) is organized into two-character
2020 SSTATE_DIR 2000 subdirectories, where the subdirectory names are based on the first two
2021 ) is organized into two-character subdirectories, where the 2001 characters of the hash.
2022 subdirectory names are based on the first two characters of the hash. 2002 If the shared state directory structure for a mirror has the same structure
2023 If the shared state directory structure for a mirror has the same 2003 as ``SSTATE_DIR``, you must specify "PATH" as part of the URI to enable the build
2024 structure as
2025 SSTATE_DIR
2026 , you must specify "PATH" as part of the URI to enable the build
2027 system to map to the appropriate subdirectory. 2004 system to map to the appropriate subdirectory.
2028 2005
2029The shared state package validity can be detected just by looking at the 2006The shared state package validity can be detected just by looking at the
@@ -2129,17 +2106,9 @@ dependencies, you must manually declare the dependencies.
2129 2106
2130 .. note:: 2107 .. note::
2131 2108
2132 By default, 2109 By default, ``foo-dev`` also has an ``RDEPENDS``-style dependency on
2133 foo-dev 2110 ``foo``, because the default value of ``RDEPENDS_${PN}-dev`` (set in
2134 also has an 2111 bitbake.conf) includes "${PN}".
2135 RDEPENDS
2136 -style dependency on
2137 foo
2138 , because the default value of
2139 RDEPENDS_${PN}-dev
2140 (set in
2141 bitbake.conf
2142 ) includes "${PN}".
2143 2112
2144 To ensure that the dependency chain is never broken, ``-dev`` and 2113 To ensure that the dependency chain is never broken, ``-dev`` and
2145 ``-dbg`` packages are always generated by default, even if the 2114 ``-dbg`` packages are always generated by default, even if the
diff --git a/documentation/transitioning-to-a-custom-environment.rst b/documentation/transitioning-to-a-custom-environment.rst
index 8dfcda379a..160152b096 100644
--- a/documentation/transitioning-to-a-custom-environment.rst
+++ b/documentation/transitioning-to-a-custom-environment.rst
@@ -47,16 +47,16 @@ Transitioning to a custom environment for systems development
47#. **Based on the layers you've chosen, make needed changes in your 47#. **Based on the layers you've chosen, make needed changes in your
48 configuration**. 48 configuration**.
49 For instance, you've chosen a machine type and added in the corresponding BSP 49 For instance, you've chosen a machine type and added in the corresponding BSP
50 layer. You'll then need to change the value of the MACHINE variable in your 50 layer. You'll then need to change the value of the ``MACHINE`` variable in your
51 configuration file (build/local.conf) to point to that same machine 51 configuration file (build/local.conf) to point to that same machine
52 type. There could be other layer-specific settings you need to change as 52 type. There could be other layer-specific settings you need to change as
53 well. Each layer has a README document that you can look at for this type of 53 well. Each layer has a ``README`` document that you can look at for this type of
54 usage information. 54 usage information.
55 55
56#. **Add a new layer for any custom recipes and metadata you create**. 56#. **Add a new layer for any custom recipes and metadata you create**.
57 Use the "bitbake-layers create-layer" tool for Yocto Project 2.4+ 57 Use the ``bitbake-layers create-layer`` tool for Yocto Project 2.4+
58 releases. If you are using a Yocto Project release earlier than 2.4, use the 58 releases. If you are using a Yocto Project release earlier than 2.4, use the
59 "yocto-layer create" tool. The "bitbake-layers" tool also provides a number 59 ``yocto-layer create`` tool. The ``bitbake-layers`` tool also provides a number
60 of other useful layer-related commands. See 60 of other useful layer-related commands. See
61 :ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the 61 :ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the
62 \`\`bitbake-layers\`\` script` section. 62 \`\`bitbake-layers\`\` script` section.