diff options
author | Michael Opdenacker <michael.opdenacker@bootlin.com> | 2024-02-09 17:48:06 +0100 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2024-02-24 16:13:28 +0000 |
commit | 025386d53ceef681d7e829ad184b6850af55619c (patch) | |
tree | 720a253731442d2b84ed443c8b143fdc23dfc493 /documentation/dev-manual | |
parent | 67efdd63c2b1d94bdc4a8da2895b3f7186e7a7c4 (diff) | |
download | poky-025386d53ceef681d7e829ad184b6850af55619c.tar.gz |
manuals: suppress excess use of "following" word
To simplify the style, replace "Following is" and "Following are"
by "here is" and "here are", sounding more natural.
In some cases, also go further by simplifying "Here are/is xxx"
by "xxx are/is" when the "are" or "is" are not two far at
the end of the sentence.
In some cases too, completely remove the sentence, when
it's redundant with the preceding title.
(From yocto-docs rev: 52ba6bb16c73cbc2c0e77496d5226c49bce786f5)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
CC: Daniel Ammann <daniel.ammann@bytesatwork.ch>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/dev-manual')
-rw-r--r-- | documentation/dev-manual/building.rst | 2 | ||||
-rw-r--r-- | documentation/dev-manual/debugging.rst | 8 | ||||
-rw-r--r-- | documentation/dev-manual/development-shell.rst | 2 | ||||
-rw-r--r-- | documentation/dev-manual/layers.rst | 8 | ||||
-rw-r--r-- | documentation/dev-manual/libraries.rst | 4 | ||||
-rw-r--r-- | documentation/dev-manual/licenses.rst | 2 | ||||
-rw-r--r-- | documentation/dev-manual/new-machine.rst | 2 | ||||
-rw-r--r-- | documentation/dev-manual/new-recipe.rst | 8 | ||||
-rw-r--r-- | documentation/dev-manual/packages.rst | 4 | ||||
-rw-r--r-- | documentation/dev-manual/prebuilt-libraries.rst | 4 | ||||
-rw-r--r-- | documentation/dev-manual/python-development-shell.rst | 2 | ||||
-rw-r--r-- | documentation/dev-manual/qemu.rst | 4 | ||||
-rw-r--r-- | documentation/dev-manual/runtime-testing.rst | 4 | ||||
-rw-r--r-- | documentation/dev-manual/speeding-up-build.rst | 4 | ||||
-rw-r--r-- | documentation/dev-manual/start.rst | 6 |
15 files changed, 32 insertions, 32 deletions
diff --git a/documentation/dev-manual/building.rst b/documentation/dev-manual/building.rst index e964bd1aee..7fcac33b75 100644 --- a/documentation/dev-manual/building.rst +++ b/documentation/dev-manual/building.rst | |||
@@ -160,7 +160,7 @@ Follow these steps to set up and execute multiple configuration builds: | |||
160 | The location for these multiconfig configuration files is specific. | 160 | The location for these multiconfig configuration files is specific. |
161 | They must reside in the current :term:`Build Directory` in a sub-directory of | 161 | They must reside in the current :term:`Build Directory` in a sub-directory of |
162 | ``conf`` named ``multiconfig`` or within a layer's ``conf`` directory | 162 | ``conf`` named ``multiconfig`` or within a layer's ``conf`` directory |
163 | under a directory named ``multiconfig``. Following is an example that defines | 163 | under a directory named ``multiconfig``. Here is an example that defines |
164 | two configuration files for the "x86" and "arm" multiconfigs: | 164 | two configuration files for the "x86" and "arm" multiconfigs: |
165 | 165 | ||
166 | .. image:: figures/multiconfig_files.png | 166 | .. image:: figures/multiconfig_files.png |
diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst index 834eade766..ce29815e9f 100644 --- a/documentation/dev-manual/debugging.rst +++ b/documentation/dev-manual/debugging.rst | |||
@@ -170,7 +170,7 @@ You can use the ``oe-pkgdata-util`` command-line utility to query | |||
170 | various package-related information. When you use the utility, you must | 170 | various package-related information. When you use the utility, you must |
171 | use it to view information on packages that have already been built. | 171 | use it to view information on packages that have already been built. |
172 | 172 | ||
173 | Following are a few of the available ``oe-pkgdata-util`` subcommands. | 173 | Here are a few of the available ``oe-pkgdata-util`` subcommands. |
174 | 174 | ||
175 | .. note:: | 175 | .. note:: |
176 | 176 | ||
@@ -608,7 +608,7 @@ logs, keep in mind the goal is to have informative logs while keeping | |||
608 | the console as "silent" as possible. Also, if you want status messages | 608 | the console as "silent" as possible. Also, if you want status messages |
609 | in the log, use the "debug" loglevel. | 609 | in the log, use the "debug" loglevel. |
610 | 610 | ||
611 | Following is an example written in Python. The code handles logging for | 611 | Here is an example written in Python. The code handles logging for |
612 | a function that determines the number of tasks needed to be run. See the | 612 | a function that determines the number of tasks needed to be run. See the |
613 | ":ref:`ref-tasks-listtasks`" | 613 | ":ref:`ref-tasks-listtasks`" |
614 | section for additional information:: | 614 | section for additional information:: |
@@ -636,7 +636,7 @@ logs, you have the same goals --- informative with minimal console output. | |||
636 | The syntax you use for recipes written in Bash is similar to that of | 636 | The syntax you use for recipes written in Bash is similar to that of |
637 | recipes written in Python described in the previous section. | 637 | recipes written in Python described in the previous section. |
638 | 638 | ||
639 | Following is an example written in Bash. The code logs the progress of | 639 | Here is an example written in Bash. The code logs the progress of |
640 | the ``do_my_function`` function:: | 640 | the ``do_my_function`` function:: |
641 | 641 | ||
642 | do_my_function() { | 642 | do_my_function() { |
@@ -1236,7 +1236,7 @@ Here are some other tips that you might find useful: | |||
1236 | "$@" | 1236 | "$@" |
1237 | } | 1237 | } |
1238 | 1238 | ||
1239 | Following are some usage examples:: | 1239 | Here are some usage examples:: |
1240 | 1240 | ||
1241 | $ g FOO # Search recursively for "FOO" | 1241 | $ g FOO # Search recursively for "FOO" |
1242 | $ g -i foo # Search recursively for "foo", ignoring case | 1242 | $ g -i foo # Search recursively for "foo", ignoring case |
diff --git a/documentation/dev-manual/development-shell.rst b/documentation/dev-manual/development-shell.rst index a18d792150..be26bcffc7 100644 --- a/documentation/dev-manual/development-shell.rst +++ b/documentation/dev-manual/development-shell.rst | |||
@@ -16,7 +16,7 @@ OpenEmbedded build system were executing them. Consequently, working | |||
16 | this way can be helpful when debugging a build or preparing software to | 16 | this way can be helpful when debugging a build or preparing software to |
17 | be used with the OpenEmbedded build system. | 17 | be used with the OpenEmbedded build system. |
18 | 18 | ||
19 | Following is an example that uses ``devshell`` on a target named | 19 | Here is an example that uses ``devshell`` on a target named |
20 | ``matchbox-desktop``:: | 20 | ``matchbox-desktop``:: |
21 | 21 | ||
22 | $ bitbake matchbox-desktop -c devshell | 22 | $ bitbake matchbox-desktop -c devshell |
diff --git a/documentation/dev-manual/layers.rst b/documentation/dev-manual/layers.rst index b3ccf633df..f7929e630e 100644 --- a/documentation/dev-manual/layers.rst +++ b/documentation/dev-manual/layers.rst | |||
@@ -82,7 +82,7 @@ Follow these general steps to create your layer without using tools: | |||
82 | LAYERVERSION_yoctobsp = "4" | 82 | LAYERVERSION_yoctobsp = "4" |
83 | LAYERSERIES_COMPAT_yoctobsp = "dunfell" | 83 | LAYERSERIES_COMPAT_yoctobsp = "dunfell" |
84 | 84 | ||
85 | Following is an explanation of the layer configuration file: | 85 | Here is an explanation of the layer configuration file: |
86 | 86 | ||
87 | - :term:`BBPATH`: Adds the layer's | 87 | - :term:`BBPATH`: Adds the layer's |
88 | root directory to BitBake's search path. Through the use of the | 88 | root directory to BitBake's search path. Through the use of the |
@@ -191,7 +191,7 @@ following list: | |||
191 | - *Structure Your Layers:* Proper use of overrides within append files | 191 | - *Structure Your Layers:* Proper use of overrides within append files |
192 | and placement of machine-specific files within your layer can ensure | 192 | and placement of machine-specific files within your layer can ensure |
193 | that a build is not using the wrong Metadata and negatively impacting | 193 | that a build is not using the wrong Metadata and negatively impacting |
194 | a build for a different machine. Following are some examples: | 194 | a build for a different machine. Here are some examples: |
195 | 195 | ||
196 | - *Modify Variables to Support a Different Machine:* Suppose you | 196 | - *Modify Variables to Support a Different Machine:* Suppose you |
197 | have a layer named ``meta-one`` that adds support for building | 197 | have a layer named ``meta-one`` that adds support for building |
@@ -513,7 +513,7 @@ In the main recipe, note the :term:`SRC_URI` | |||
513 | variable, which tells the OpenEmbedded build system where to find files | 513 | variable, which tells the OpenEmbedded build system where to find files |
514 | during the build. | 514 | during the build. |
515 | 515 | ||
516 | Following is the append file, which is named ``formfactor_0.0.bbappend`` | 516 | Here is the append file, which is named ``formfactor_0.0.bbappend`` |
517 | and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The | 517 | and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The |
518 | file is in the layer at ``recipes-bsp/formfactor``:: | 518 | file is in the layer at ``recipes-bsp/formfactor``:: |
519 | 519 | ||
@@ -588,7 +588,7 @@ Directory`. Here is the main ``xserver-xf86-config`` recipe, which is named | |||
588 | fi | 588 | fi |
589 | } | 589 | } |
590 | 590 | ||
591 | Following is the append file, which is named ``xserver-xf86-config_%.bbappend`` | 591 | Here is the append file, which is named ``xserver-xf86-config_%.bbappend`` |
592 | and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The | 592 | and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The |
593 | file is in the layer at ``recipes-graphics/xorg-xserver``:: | 593 | file is in the layer at ``recipes-graphics/xorg-xserver``:: |
594 | 594 | ||
diff --git a/documentation/dev-manual/libraries.rst b/documentation/dev-manual/libraries.rst index ae4ca27209..521dbb9a7c 100644 --- a/documentation/dev-manual/libraries.rst +++ b/documentation/dev-manual/libraries.rst | |||
@@ -37,7 +37,7 @@ library files. | |||
37 | Some previously released versions of the Yocto Project defined the | 37 | Some previously released versions of the Yocto Project defined the |
38 | static library files through ``${PN}-dev``. | 38 | static library files through ``${PN}-dev``. |
39 | 39 | ||
40 | Following is part of the BitBake configuration file, where you can see | 40 | Here is the part of the BitBake configuration file, where you can see |
41 | how the static library files are defined:: | 41 | how the static library files are defined:: |
42 | 42 | ||
43 | PACKAGE_BEFORE_PN ?= "" | 43 | PACKAGE_BEFORE_PN ?= "" |
@@ -177,7 +177,7 @@ Additional Implementation Details | |||
177 | --------------------------------- | 177 | --------------------------------- |
178 | 178 | ||
179 | There are generic implementation details as well as details that are specific to | 179 | There are generic implementation details as well as details that are specific to |
180 | package management systems. Following are implementation details | 180 | package management systems. Here are implementation details |
181 | that exist regardless of the package management system: | 181 | that exist regardless of the package management system: |
182 | 182 | ||
183 | - The typical convention used for the class extension code as used by | 183 | - The typical convention used for the class extension code as used by |
diff --git a/documentation/dev-manual/licenses.rst b/documentation/dev-manual/licenses.rst index 57713effa0..bffff3675f 100644 --- a/documentation/dev-manual/licenses.rst +++ b/documentation/dev-manual/licenses.rst | |||
@@ -27,7 +27,7 @@ Specifying the ``LIC_FILES_CHKSUM`` Variable | |||
27 | -------------------------------------------- | 27 | -------------------------------------------- |
28 | 28 | ||
29 | The :term:`LIC_FILES_CHKSUM` variable contains checksums of the license text | 29 | The :term:`LIC_FILES_CHKSUM` variable contains checksums of the license text |
30 | in the source code for the recipe. Following is an example of how to | 30 | in the source code for the recipe. Here is an example of how to |
31 | specify :term:`LIC_FILES_CHKSUM`:: | 31 | specify :term:`LIC_FILES_CHKSUM`:: |
32 | 32 | ||
33 | LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \ | 33 | LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \ |
diff --git a/documentation/dev-manual/new-machine.rst b/documentation/dev-manual/new-machine.rst index 6b41d24db4..469b2d395a 100644 --- a/documentation/dev-manual/new-machine.rst +++ b/documentation/dev-manual/new-machine.rst | |||
@@ -104,7 +104,7 @@ contains directories for specific machines such as ``qemuarm`` and | |||
104 | defaults, see the ``meta/recipes-bsp/formfactor/files/config`` file | 104 | defaults, see the ``meta/recipes-bsp/formfactor/files/config`` file |
105 | found in the same area. | 105 | found in the same area. |
106 | 106 | ||
107 | Following is an example for "qemuarm" machine:: | 107 | Here is an example for "qemuarm" machine:: |
108 | 108 | ||
109 | HAVE_TOUCHSCREEN=1 | 109 | HAVE_TOUCHSCREEN=1 |
110 | HAVE_KEYBOARD=1 | 110 | HAVE_KEYBOARD=1 |
diff --git a/documentation/dev-manual/new-recipe.rst b/documentation/dev-manual/new-recipe.rst index 2c1033eb35..61fc2eb122 100644 --- a/documentation/dev-manual/new-recipe.rst +++ b/documentation/dev-manual/new-recipe.rst | |||
@@ -100,7 +100,7 @@ command:: | |||
100 | 100 | ||
101 | Running ``recipetool create -o OUTFILE`` creates the base recipe and | 101 | Running ``recipetool create -o OUTFILE`` creates the base recipe and |
102 | locates it properly in the layer that contains your source files. | 102 | locates it properly in the layer that contains your source files. |
103 | Following are some syntax examples: | 103 | Here are some syntax examples: |
104 | 104 | ||
105 | - Use this syntax to generate a recipe based on source. Once generated, | 105 | - Use this syntax to generate a recipe based on source. Once generated, |
106 | the recipe resides in the existing source code layer:: | 106 | the recipe resides in the existing source code layer:: |
@@ -1232,7 +1232,7 @@ inherit the :ref:`ref-classes-autotools` class, which contains the definitions | |||
1232 | of all the steps needed to build an Autotool-based application. The result of | 1232 | of all the steps needed to build an Autotool-based application. The result of |
1233 | the build is automatically packaged. And, if the application uses NLS for | 1233 | the build is automatically packaged. And, if the application uses NLS for |
1234 | localization, packages with local information are generated (one package per | 1234 | localization, packages with local information are generated (one package per |
1235 | language). Following is one example: (``hello_2.3.bb``):: | 1235 | language). Here is one example: (``hello_2.3.bb``):: |
1236 | 1236 | ||
1237 | SUMMARY = "GNU Helloworld application" | 1237 | SUMMARY = "GNU Helloworld application" |
1238 | SECTION = "examples" | 1238 | SECTION = "examples" |
@@ -1285,7 +1285,7 @@ Splitting an Application into Multiple Packages | |||
1285 | You can use the variables :term:`PACKAGES` and :term:`FILES` to split an | 1285 | You can use the variables :term:`PACKAGES` and :term:`FILES` to split an |
1286 | application into multiple packages. | 1286 | application into multiple packages. |
1287 | 1287 | ||
1288 | Following is an example that uses the ``libxpm`` recipe. By default, | 1288 | Here is an example that uses the ``libxpm`` recipe. By default, |
1289 | this recipe generates a single package that contains the library along | 1289 | this recipe generates a single package that contains the library along |
1290 | with a few binaries. You can modify the recipe to split the binaries | 1290 | with a few binaries. You can modify the recipe to split the binaries |
1291 | into separate packages:: | 1291 | into separate packages:: |
@@ -1510,7 +1510,7 @@ in the BitBake User Manual. | |||
1510 | when you make the assignment, but this is not generally needed. | 1510 | when you make the assignment, but this is not generally needed. |
1511 | 1511 | ||
1512 | - *Quote All Assignments ("value"):* Use double quotes around values in | 1512 | - *Quote All Assignments ("value"):* Use double quotes around values in |
1513 | all variable assignments (e.g. ``"value"``). Following is an example:: | 1513 | all variable assignments (e.g. ``"value"``). Here is an example:: |
1514 | 1514 | ||
1515 | VAR1 = "${OTHERVAR}" | 1515 | VAR1 = "${OTHERVAR}" |
1516 | VAR2 = "The version is ${PV}" | 1516 | VAR2 = "The version is ${PV}" |
diff --git a/documentation/dev-manual/packages.rst b/documentation/dev-manual/packages.rst index 79f21d9f34..0e991e409a 100644 --- a/documentation/dev-manual/packages.rst +++ b/documentation/dev-manual/packages.rst | |||
@@ -365,7 +365,7 @@ For more examples that show how to use ``do_split_packages``, see the | |||
365 | directory of the ``poky`` :ref:`source repository <overview-manual/development-environment:yocto project source repositories>`. You can | 365 | directory of the ``poky`` :ref:`source repository <overview-manual/development-environment:yocto project source repositories>`. You can |
366 | also find examples in ``meta/classes-recipe/kernel.bbclass``. | 366 | also find examples in ``meta/classes-recipe/kernel.bbclass``. |
367 | 367 | ||
368 | Following is a reference that shows ``do_split_packages`` mandatory and | 368 | Here is a reference that shows ``do_split_packages`` mandatory and |
369 | optional arguments:: | 369 | optional arguments:: |
370 | 370 | ||
371 | Mandatory arguments | 371 | Mandatory arguments |
@@ -1123,7 +1123,7 @@ The ``devtool edit-recipe`` command lets you take a look at the recipe:: | |||
1123 | ... | 1123 | ... |
1124 | LICENSE:${PN}-vary = "MIT" | 1124 | LICENSE:${PN}-vary = "MIT" |
1125 | 1125 | ||
1126 | Here are three key points in the previous example: | 1126 | Three key points in the previous example are: |
1127 | 1127 | ||
1128 | - :term:`SRC_URI` uses the NPM | 1128 | - :term:`SRC_URI` uses the NPM |
1129 | scheme so that the NPM fetcher is used. | 1129 | scheme so that the NPM fetcher is used. |
diff --git a/documentation/dev-manual/prebuilt-libraries.rst b/documentation/dev-manual/prebuilt-libraries.rst index b80a844e93..a05f39ca1e 100644 --- a/documentation/dev-manual/prebuilt-libraries.rst +++ b/documentation/dev-manual/prebuilt-libraries.rst | |||
@@ -148,8 +148,8 @@ recipe. By default, ``libfoo.so`` gets packaged into ``${PN}-dev``, which | |||
148 | triggers a QA warning that a non-symlink library is in a ``-dev`` package, | 148 | triggers a QA warning that a non-symlink library is in a ``-dev`` package, |
149 | and binaries in the same recipe link to the library in ``${PN}-dev``, | 149 | and binaries in the same recipe link to the library in ``${PN}-dev``, |
150 | which triggers more QA warnings. To solve this problem, you need to package the | 150 | which triggers more QA warnings. To solve this problem, you need to package the |
151 | unversioned library into ``${PN}`` where it belongs. The following are the abridged | 151 | unversioned library into ``${PN}`` where it belongs. The abridged |
152 | default :term:`FILES` variables in ``bitbake.conf``:: | 152 | default :term:`FILES` variables in ``bitbake.conf`` are:: |
153 | 153 | ||
154 | SOLIBS = ".so.*" | 154 | SOLIBS = ".so.*" |
155 | SOLIBSDEV = ".so" | 155 | SOLIBSDEV = ".so" |
diff --git a/documentation/dev-manual/python-development-shell.rst b/documentation/dev-manual/python-development-shell.rst index 2dc6a3f138..81a5c43472 100644 --- a/documentation/dev-manual/python-development-shell.rst +++ b/documentation/dev-manual/python-development-shell.rst | |||
@@ -35,7 +35,7 @@ system were executing them. Consequently, working this way can be | |||
35 | helpful when debugging a build or preparing software to be used with the | 35 | helpful when debugging a build or preparing software to be used with the |
36 | OpenEmbedded build system. | 36 | OpenEmbedded build system. |
37 | 37 | ||
38 | Following is an example that uses ``pydevshell`` on a target named | 38 | Here is an example that uses ``pydevshell`` on a target named |
39 | ``matchbox-desktop``:: | 39 | ``matchbox-desktop``:: |
40 | 40 | ||
41 | $ bitbake matchbox-desktop -c pydevshell | 41 | $ bitbake matchbox-desktop -c pydevshell |
diff --git a/documentation/dev-manual/qemu.rst b/documentation/dev-manual/qemu.rst index d431ea4b99..19f3e40d63 100644 --- a/documentation/dev-manual/qemu.rst +++ b/documentation/dev-manual/qemu.rst | |||
@@ -311,7 +311,7 @@ timestamp when it needs to look for an image. Minimally, through the use | |||
311 | of options, you must provide either a machine name, a virtual machine | 311 | of options, you must provide either a machine name, a virtual machine |
312 | image (``*wic.vmdk``), or a kernel image (``*.bin``). | 312 | image (``*wic.vmdk``), or a kernel image (``*.bin``). |
313 | 313 | ||
314 | Following is the command-line help output for the ``runqemu`` command:: | 314 | Here is the command-line help output for the ``runqemu`` command:: |
315 | 315 | ||
316 | $ runqemu --help | 316 | $ runqemu --help |
317 | 317 | ||
@@ -353,7 +353,7 @@ Following is the command-line help output for the ``runqemu`` command:: | |||
353 | ``runqemu`` Command-Line Options | 353 | ``runqemu`` Command-Line Options |
354 | ================================ | 354 | ================================ |
355 | 355 | ||
356 | Following is a description of ``runqemu`` options you can provide on the | 356 | Here is a description of ``runqemu`` options you can provide on the |
357 | command line: | 357 | command line: |
358 | 358 | ||
359 | .. note:: | 359 | .. note:: |
diff --git a/documentation/dev-manual/runtime-testing.rst b/documentation/dev-manual/runtime-testing.rst index 1a2e9ec4fe..7a2b42f25a 100644 --- a/documentation/dev-manual/runtime-testing.rst +++ b/documentation/dev-manual/runtime-testing.rst | |||
@@ -193,7 +193,7 @@ perform a one-time setup of your controller image by doing the following: | |||
193 | "controller" image and you can customize the image recipe as you would | 193 | "controller" image and you can customize the image recipe as you would |
194 | any other recipe. | 194 | any other recipe. |
195 | 195 | ||
196 | Here are the image recipe requirements: | 196 | Image recipe requirements are: |
197 | 197 | ||
198 | - Inherits ``core-image`` so that kernel modules are installed. | 198 | - Inherits ``core-image`` so that kernel modules are installed. |
199 | 199 | ||
@@ -572,7 +572,7 @@ data: | |||
572 | When set to "true", the package is not automatically installed into | 572 | When set to "true", the package is not automatically installed into |
573 | the DUT. | 573 | the DUT. |
574 | 574 | ||
575 | Following is an example JSON file that handles test "foo" installing | 575 | Here is an example JSON file that handles test "foo" installing |
576 | package "bar" and test "foobar" installing packages "foo" and "bar". | 576 | package "bar" and test "foobar" installing packages "foo" and "bar". |
577 | Once the test is complete, the packages are removed from the DUT:: | 577 | Once the test is complete, the packages are removed from the DUT:: |
578 | 578 | ||
diff --git a/documentation/dev-manual/speeding-up-build.rst b/documentation/dev-manual/speeding-up-build.rst index 31b6f75ab0..6e0d7873ac 100644 --- a/documentation/dev-manual/speeding-up-build.rst +++ b/documentation/dev-manual/speeding-up-build.rst | |||
@@ -33,7 +33,7 @@ auto-scaling ensures that the build system fundamentally takes advantage | |||
33 | of potential parallel operations during the build based on the build | 33 | of potential parallel operations during the build based on the build |
34 | machine's capabilities. | 34 | machine's capabilities. |
35 | 35 | ||
36 | Following are additional factors that can affect build speed: | 36 | Additional factors that can affect build speed are: |
37 | 37 | ||
38 | - File system type: The file system type that the build is being | 38 | - File system type: The file system type that the build is being |
39 | performed on can also influence performance. Using ``ext4`` is | 39 | performed on can also influence performance. Using ``ext4`` is |
@@ -88,7 +88,7 @@ that can help you speed up the build: | |||
88 | variable to "1". | 88 | variable to "1". |
89 | 89 | ||
90 | - Disable static library generation for recipes derived from | 90 | - Disable static library generation for recipes derived from |
91 | ``autoconf`` or ``libtool``: Following is an example showing how to | 91 | ``autoconf`` or ``libtool``: Here is an example showing how to |
92 | disable static libraries and still provide an override to handle | 92 | disable static libraries and still provide an override to handle |
93 | exceptions:: | 93 | exceptions:: |
94 | 94 | ||
diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst index b108337795..8539bc0889 100644 --- a/documentation/dev-manual/start.rst +++ b/documentation/dev-manual/start.rst | |||
@@ -36,7 +36,7 @@ particular working environment and set of practices. | |||
36 | equipment together and set up your development environment's | 36 | equipment together and set up your development environment's |
37 | hardware topology. | 37 | hardware topology. |
38 | 38 | ||
39 | Here are possible roles: | 39 | Possible roles are: |
40 | 40 | ||
41 | - *Application Developer:* This type of developer does application | 41 | - *Application Developer:* This type of developer does application |
42 | level work on top of an existing software stack. | 42 | level work on top of an existing software stack. |
@@ -99,7 +99,7 @@ particular working environment and set of practices. | |||
99 | 99 | ||
100 | #. *Set up the Application Development Machines:* As mentioned earlier, | 100 | #. *Set up the Application Development Machines:* As mentioned earlier, |
101 | application developers are creating applications on top of existing | 101 | application developers are creating applications on top of existing |
102 | software stacks. Following are some best practices for setting up | 102 | software stacks. Here are some best practices for setting up |
103 | machines used for application development: | 103 | machines used for application development: |
104 | 104 | ||
105 | - Use a pre-built toolchain that contains the software stack | 105 | - Use a pre-built toolchain that contains the software stack |
@@ -118,7 +118,7 @@ particular working environment and set of practices. | |||
118 | 118 | ||
119 | #. *Set up the Core Development Machines:* As mentioned earlier, core | 119 | #. *Set up the Core Development Machines:* As mentioned earlier, core |
120 | developers work on the contents of the operating system itself. | 120 | developers work on the contents of the operating system itself. |
121 | Following are some best practices for setting up machines used for | 121 | Here are some best practices for setting up machines used for |
122 | developing images: | 122 | developing images: |
123 | 123 | ||
124 | - Have the :term:`OpenEmbedded Build System` available on | 124 | - Have the :term:`OpenEmbedded Build System` available on |