diff options
author | Nicolas Dechesne <nicolas.dechesne@linaro.org> | 2020-07-24 16:27:54 +0200 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2020-09-17 10:09:33 +0100 |
commit | c473fa229239752367c5d573160fc8738cf1907e (patch) | |
tree | f8520ba3aa3cf911333dbd31e38e9a52203a0285 /documentation/sdk-manual/sdk-extensible.rst | |
parent | 4cd953989de42c7a83f666c23e077d53b016a1f1 (diff) | |
download | poky-c473fa229239752367c5d573160fc8738cf1907e.tar.gz |
sphinx: fix internal links
Many of the internal links were not converted probably from DocBook
using pandoc. After looking at the various patterns, the follow series
of 'naive' Python regexp were used to perform some additional
automatic conversion.
Also, since we rely on built-in glossary, all links to terms need to
use the sphinx :term: syntax.
This commit is generated using the following Python series of regexp:
line = re.sub("`+(\w+)`* <(\&YOCTO_DOCS_REF_URL;)?#var-\\1>`__",
":term:`\\1`",
line)
line = re.sub("`+do_([a-z_]+)`* <(\&YOCTO_DOCS_REF_URL;)?#ref-tasks-\\1>`__",
":ref:`ref-tasks-\\1`",
line)
line = re.sub("`+([a-z_\-\*\.]+).bbclass`* <(\&YOCTO_DOCS_REF_URL;)?#ref-classes-\\1>`__",
":ref:`\\1.bbclass <ref-classes-\\1>`",
line)
line = re.sub("`+([a-z_\-\*\.]+)`* <(\&YOCTO_DOCS_REF_URL;)?#ref-classes-\\1>`__",
":ref:`\\1 <ref-classes-\\1>`",
line)
line = re.sub("`Source Directory <(\&YOCTO_DOCS_REF_URL;)?#source-directory>`__",
":term:`Source Directory`",
line)
line = re.sub("`Build Directory <(\&YOCTO_DOCS_REF_URL;)?#build-directory>`__",
":term:`Build Directory`",
line)
line = re.sub("`Metadata <(\&YOCTO_DOCS_REF_URL;)?#metadata>`__",
":term:`Metadata`",
line)
line = re.sub("`BitBake <(\&YOCTO_DOCS_REF_URL;)?#bitbake-term>`__",
":term:`BitBake`",
line)
line = re.sub("`Images <(\&YOCTO_DOCS_REF_URL;)?#ref-images>`__",
":ref:`ref-manual/ref-images:Images`",
line)
line = re.sub("`Classes <(\&YOCTO_DOCS_REF_URL;)?#ref-classes>`__",
":ref:`ref-manual/ref-classes:Classes`",
line)
line = re.sub("`workspace <(\&YOCTO_DOCS_REF_URL;)?#devtool-the-workspace-layer-structure>`__",
":ref:`devtool-the-workspace-layer-structure`",
line)
line = re.sub("`Open-?Embedded b?B?uild s?S?ystem <(\&YOCTO_DOCS_REF_URL;)?#build-system-term>`__",
":term:`OpenEmbedded Build System`",
line)
line = re.sub("`(OpenEmbedded-Core )?(\(?OE-Core\)? )?<(\&YOCTO_DOCS_REF_URL;)?#oe-core>`__",
":term:`OpenEmbedded-Core (OE-Core)`",
line)
It won't catch multiline strings, but it catches a very large number
of occurences!
(From yocto-docs rev: 3f537d17de5b1fb76ba3bee196481984a4826378)
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/sdk-manual/sdk-extensible.rst')
-rw-r--r-- | documentation/sdk-manual/sdk-extensible.rst | 64 |
1 files changed, 32 insertions, 32 deletions
diff --git a/documentation/sdk-manual/sdk-extensible.rst b/documentation/sdk-manual/sdk-extensible.rst index cccc857d46..17cd08a25c 100644 --- a/documentation/sdk-manual/sdk-extensible.rst +++ b/documentation/sdk-manual/sdk-extensible.rst | |||
@@ -148,8 +148,8 @@ SDK environment now set up; additionally you may now run devtool to | |||
148 | perform development tasks. Run devtool --help for further details. | 148 | perform development tasks. Run devtool --help for further details. |
149 | Running the setup script defines many environment variables needed in | 149 | Running the setup script defines many environment variables needed in |
150 | order to use the SDK (e.g. ``PATH``, | 150 | order to use the SDK (e.g. ``PATH``, |
151 | ```CC`` <&YOCTO_DOCS_REF_URL;#var-CC>`__, | 151 | :term:`CC`, |
152 | ```LD`` <&YOCTO_DOCS_REF_URL;#var-LD>`__, and so forth). If you want to | 152 | :term:`LD`, and so forth). If you want to |
153 | see all the environment variables the script exports, examine the | 153 | see all the environment variables the script exports, examine the |
154 | installation file itself. | 154 | installation file itself. |
155 | 155 | ||
@@ -215,7 +215,7 @@ Use ``devtool add`` to Add an Application | |||
215 | 215 | ||
216 | The ``devtool add`` command generates a new recipe based on existing | 216 | The ``devtool add`` command generates a new recipe based on existing |
217 | source code. This command takes advantage of the | 217 | source code. This command takes advantage of the |
218 | `workspace <&YOCTO_DOCS_REF_URL;#devtool-the-workspace-layer-structure>`__ | 218 | :ref:`devtool-the-workspace-layer-structure` |
219 | layer that many ``devtool`` commands use. The command is flexible enough | 219 | layer that many ``devtool`` commands use. The command is flexible enough |
220 | to allow you to extract source code into both the workspace or a | 220 | to allow you to extract source code into both the workspace or a |
221 | separate local Git repository and to use existing code that does not | 221 | separate local Git repository and to use existing code that does not |
@@ -397,7 +397,7 @@ command: | |||
397 | The following command identifies the recipe and, by default, | 397 | The following command identifies the recipe and, by default, |
398 | extracts the source files: $ devtool modify recipe Once | 398 | extracts the source files: $ devtool modify recipe Once |
399 | ``devtool``\ locates the recipe, ``devtool`` uses the recipe's | 399 | ``devtool``\ locates the recipe, ``devtool`` uses the recipe's |
400 | ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ statements to | 400 | :term:`SRC_URI` statements to |
401 | locate the source code and any local patch files from other | 401 | locate the source code and any local patch files from other |
402 | developers. | 402 | developers. |
403 | 403 | ||
@@ -569,7 +569,7 @@ counterparts. | |||
569 | The ``devtool upgrade`` command is flexible enough to allow you to | 569 | The ``devtool upgrade`` command is flexible enough to allow you to |
570 | specify source code revision and versioning schemes, extract code into | 570 | specify source code revision and versioning schemes, extract code into |
571 | or out of the ``devtool`` | 571 | or out of the ``devtool`` |
572 | `workspace <&YOCTO_DOCS_REF_URL;#devtool-the-workspace-layer-structure>`__, | 572 | :ref:`devtool-the-workspace-layer-structure`, |
573 | and work with any source file forms that the | 573 | and work with any source file forms that the |
574 | `fetchers <&YOCTO_DOCS_BB_URL;#bb-fetchers>`__ support. | 574 | `fetchers <&YOCTO_DOCS_BB_URL;#bb-fetchers>`__ support. |
575 | 575 | ||
@@ -584,7 +584,7 @@ The following diagram shows the common development flow used with the | |||
584 | workspace. | 584 | workspace. |
585 | 585 | ||
586 | - The source files for the new release exist in the same location | 586 | - The source files for the new release exist in the same location |
587 | pointed to by ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ | 587 | pointed to by :term:`SRC_URI` |
588 | in the recipe (e.g. a tarball with the new version number in the | 588 | in the recipe (e.g. a tarball with the new version number in the |
589 | name, or as a different revision in the upstream Git repository). | 589 | name, or as a different revision in the upstream Git repository). |
590 | 590 | ||
@@ -594,7 +594,7 @@ The following diagram shows the common development flow used with the | |||
594 | use the newer version of the software: $ devtool upgrade -V version | 594 | use the newer version of the software: $ devtool upgrade -V version |
595 | recipe By default, the ``devtool upgrade`` command extracts source | 595 | recipe By default, the ``devtool upgrade`` command extracts source |
596 | code into the ``sources`` directory in the | 596 | code into the ``sources`` directory in the |
597 | `workspace <&YOCTO_DOCS_REF_URL;#devtool-the-workspace-layer-structure>`__. | 597 | :ref:`devtool-the-workspace-layer-structure`. |
598 | If you want the code extracted to any other location, you need to | 598 | If you want the code extracted to any other location, you need to |
599 | provide the srctree positional argument with the command as follows: | 599 | provide the srctree positional argument with the command as follows: |
600 | $ devtool upgrade -V version recipe srctree | 600 | $ devtool upgrade -V version recipe srctree |
@@ -773,7 +773,7 @@ Dependency Detection and Mapping | |||
773 | The ``devtool add`` command attempts to detect build-time dependencies | 773 | The ``devtool add`` command attempts to detect build-time dependencies |
774 | and map them to other recipes in the system. During this mapping, the | 774 | and map them to other recipes in the system. During this mapping, the |
775 | command fills in the names of those recipes as part of the | 775 | command fills in the names of those recipes as part of the |
776 | ```DEPENDS`` <&YOCTO_DOCS_REF_URL;#var-DEPENDS>`__ variable within the | 776 | :term:`DEPENDS` variable within the |
777 | recipe. If a dependency cannot be mapped, ``devtool`` places a comment | 777 | recipe. If a dependency cannot be mapped, ``devtool`` places a comment |
778 | in the recipe indicating such. The inability to map a dependency can | 778 | in the recipe indicating such. The inability to map a dependency can |
779 | result from naming not being recognized or because the dependency simply | 779 | result from naming not being recognized or because the dependency simply |
@@ -807,13 +807,13 @@ License Detection | |||
807 | The ``devtool add`` command attempts to determine if the software you | 807 | The ``devtool add`` command attempts to determine if the software you |
808 | are adding is able to be distributed under a common, open-source | 808 | are adding is able to be distributed under a common, open-source |
809 | license. If so, the command sets the | 809 | license. If so, the command sets the |
810 | ```LICENSE`` <&YOCTO_DOCS_REF_URL;#var-LICENSE>`__ value accordingly. | 810 | :term:`LICENSE` value accordingly. |
811 | You should double-check the value added by the command against the | 811 | You should double-check the value added by the command against the |
812 | documentation or source files for the software you are building and, if | 812 | documentation or source files for the software you are building and, if |
813 | necessary, update that ``LICENSE`` value. | 813 | necessary, update that ``LICENSE`` value. |
814 | 814 | ||
815 | The ``devtool add`` command also sets the | 815 | The ``devtool add`` command also sets the |
816 | ```LIC_FILES_CHKSUM`` <&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM>`__ | 816 | :term:`LIC_FILES_CHKSUM` |
817 | value to point to all files that appear to be license-related. Realize | 817 | value to point to all files that appear to be license-related. Realize |
818 | that license statements often appear in comments at the top of source | 818 | that license statements often appear in comments at the top of source |
819 | files or within the documentation. In such cases, the command does not | 819 | files or within the documentation. In such cases, the command does not |
@@ -842,7 +842,7 @@ open-source software. Unfortunately, Makefiles are often not written | |||
842 | with cross-compilation in mind. Thus, ``devtool add`` often cannot do | 842 | with cross-compilation in mind. Thus, ``devtool add`` often cannot do |
843 | very much to ensure that these Makefiles build correctly. It is very | 843 | very much to ensure that these Makefiles build correctly. It is very |
844 | common, for example, to explicitly call ``gcc`` instead of using the | 844 | common, for example, to explicitly call ``gcc`` instead of using the |
845 | ```CC`` <&YOCTO_DOCS_REF_URL;#var-CC>`__ variable. Usually, in a | 845 | :term:`CC` variable. Usually, in a |
846 | cross-compilation environment, ``gcc`` is the compiler for the build | 846 | cross-compilation environment, ``gcc`` is the compiler for the build |
847 | host and the cross-compiler is named something similar to | 847 | host and the cross-compiler is named something similar to |
848 | ``arm-poky-linux-gnueabi-gcc`` and might require arguments (e.g. to | 848 | ``arm-poky-linux-gnueabi-gcc`` and might require arguments (e.g. to |
@@ -869,8 +869,8 @@ mind: | |||
869 | sets the default using the "?=" operator, or you can alternatively | 869 | sets the default using the "?=" operator, or you can alternatively |
870 | force the value on the ``make`` command line. To force the value on | 870 | force the value on the ``make`` command line. To force the value on |
871 | the command line, add the variable setting to | 871 | the command line, add the variable setting to |
872 | ```EXTRA_OEMAKE`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_OEMAKE>`__ or | 872 | :term:`EXTRA_OEMAKE` or |
873 | ```PACKAGECONFIG_CONFARGS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS>`__ | 873 | :term:`PACKAGECONFIG_CONFARGS` |
874 | within the recipe. Here is an example using ``EXTRA_OEMAKE``: | 874 | within the recipe. Here is an example using ``EXTRA_OEMAKE``: |
875 | EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'" In the above example, | 875 | EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'" In the above example, |
876 | single quotes are used around the variable settings as the values are | 876 | single quotes are used around the variable settings as the values are |
@@ -951,7 +951,7 @@ repository or local source tree. To add modules this way, use | |||
951 | https://github.com/diversario/node-ssdp In this example, ``devtool`` | 951 | https://github.com/diversario/node-ssdp In this example, ``devtool`` |
952 | fetches the specified Git repository, detects the code as Node.js code, | 952 | fetches the specified Git repository, detects the code as Node.js code, |
953 | fetches dependencies using ``npm``, and sets | 953 | fetches dependencies using ``npm``, and sets |
954 | ```SRC_URI`` <&YOCTO_DOCS_REF_URL;#var-SRC_URI>`__ accordingly. | 954 | :term:`SRC_URI` accordingly. |
955 | 955 | ||
956 | .. _sdk-working-with-recipes: | 956 | .. _sdk-working-with-recipes: |
957 | 957 | ||
@@ -976,8 +976,8 @@ build progresses as follows: | |||
976 | For recipes in the workspace, fetching and unpacking is disabled as the | 976 | For recipes in the workspace, fetching and unpacking is disabled as the |
977 | source tree has already been prepared and is persistent. Each of these | 977 | source tree has already been prepared and is persistent. Each of these |
978 | build steps is defined as a function (task), usually with a "do_" prefix | 978 | build steps is defined as a function (task), usually with a "do_" prefix |
979 | (e.g. ```do_fetch`` <&YOCTO_DOCS_REF_URL;#ref-tasks-fetch>`__, | 979 | (e.g. :ref:`ref-tasks-fetch`, |
980 | ```do_unpack`` <&YOCTO_DOCS_REF_URL;#ref-tasks-unpack>`__, and so | 980 | :ref:`ref-tasks-unpack`, and so |
981 | forth). These functions are typically shell scripts but can instead be | 981 | forth). These functions are typically shell scripts but can instead be |
982 | written in Python. | 982 | written in Python. |
983 | 983 | ||
@@ -986,7 +986,7 @@ does not include complete instructions for building the software. | |||
986 | Instead, common functionality is encapsulated in classes inherited with | 986 | Instead, common functionality is encapsulated in classes inherited with |
987 | the ``inherit`` directive. This technique leaves the recipe to describe | 987 | the ``inherit`` directive. This technique leaves the recipe to describe |
988 | just the things that are specific to the software being built. A | 988 | just the things that are specific to the software being built. A |
989 | ```base`` <&YOCTO_DOCS_REF_URL;#ref-classes-base>`__ class exists that | 989 | :ref:`base <ref-classes-base>` class exists that |
990 | is implicitly inherited by all recipes and provides the functionality | 990 | is implicitly inherited by all recipes and provides the functionality |
991 | that most recipes typically need. | 991 | that most recipes typically need. |
992 | 992 | ||
@@ -1011,9 +1011,9 @@ links created within the source tree: | |||
1011 | useful: | 1011 | useful: |
1012 | 1012 | ||
1013 | - ``image/``: Contains all of the files installed during the | 1013 | - ``image/``: Contains all of the files installed during the |
1014 | ```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ stage. | 1014 | :ref:`ref-tasks-install` stage. |
1015 | Within a recipe, this directory is referred to by the expression | 1015 | Within a recipe, this directory is referred to by the expression |
1016 | ``${``\ ```D`` <&YOCTO_DOCS_REF_URL;#var-D>`__\ ``}``. | 1016 | ``${``\ :term:`D`\ ``}``. |
1017 | 1017 | ||
1018 | - ``sysroot-destdir/``: Contains a subset of files installed within | 1018 | - ``sysroot-destdir/``: Contains a subset of files installed within |
1019 | ``do_install`` that have been put into the shared sysroot. For | 1019 | ``do_install`` that have been put into the shared sysroot. For |
@@ -1035,16 +1035,16 @@ Setting Configure Arguments | |||
1035 | If the software your recipe is building uses GNU autoconf, then a fixed | 1035 | If the software your recipe is building uses GNU autoconf, then a fixed |
1036 | set of arguments is passed to it to enable cross-compilation plus any | 1036 | set of arguments is passed to it to enable cross-compilation plus any |
1037 | extras specified by | 1037 | extras specified by |
1038 | ```EXTRA_OECONF`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_OECONF>`__ or | 1038 | :term:`EXTRA_OECONF` or |
1039 | ```PACKAGECONFIG_CONFARGS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS>`__ | 1039 | :term:`PACKAGECONFIG_CONFARGS` |
1040 | set within the recipe. If you wish to pass additional options, add them | 1040 | set within the recipe. If you wish to pass additional options, add them |
1041 | to ``EXTRA_OECONF`` or ``PACKAGECONFIG_CONFARGS``. Other supported build | 1041 | to ``EXTRA_OECONF`` or ``PACKAGECONFIG_CONFARGS``. Other supported build |
1042 | tools have similar variables (e.g. | 1042 | tools have similar variables (e.g. |
1043 | ```EXTRA_OECMAKE`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_OECMAKE>`__ for | 1043 | :term:`EXTRA_OECMAKE` for |
1044 | CMake, ```EXTRA_OESCONS`` <&YOCTO_DOCS_REF_URL;#var-EXTRA_OESCONS>`__ | 1044 | CMake, :term:`EXTRA_OESCONS` |
1045 | for Scons, and so forth). If you need to pass anything on the ``make`` | 1045 | for Scons, and so forth). If you need to pass anything on the ``make`` |
1046 | command line, you can use ``EXTRA_OEMAKE`` or the | 1046 | command line, you can use ``EXTRA_OEMAKE`` or the |
1047 | ```PACKAGECONFIG_CONFARGS`` <&YOCTO_DOCS_REF_URL;#var-PACKAGECONFIG_CONFARGS>`__ | 1047 | :term:`PACKAGECONFIG_CONFARGS` |
1048 | variables to do so. | 1048 | variables to do so. |
1049 | 1049 | ||
1050 | You can use the ``devtool configure-help`` command to help you set the | 1050 | You can use the ``devtool configure-help`` command to help you set the |
@@ -1071,8 +1071,8 @@ the build host. | |||
1071 | 1071 | ||
1072 | Recipes should never write files directly into the sysroot. Instead, | 1072 | Recipes should never write files directly into the sysroot. Instead, |
1073 | files should be installed into standard locations during the | 1073 | files should be installed into standard locations during the |
1074 | ```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ task within | 1074 | :ref:`ref-tasks-install` task within |
1075 | the ``${``\ ```D`` <&YOCTO_DOCS_REF_URL;#var-D>`__\ ``}`` directory. A | 1075 | the ``${``\ :term:`D`\ ``}`` directory. A |
1076 | subset of these files automatically goes into the sysroot. The reason | 1076 | subset of these files automatically goes into the sysroot. The reason |
1077 | for this limitation is that almost all files that go into the sysroot | 1077 | for this limitation is that almost all files that go into the sysroot |
1078 | are cataloged in manifests in order to ensure they can be removed later | 1078 | are cataloged in manifests in order to ensure they can be removed later |
@@ -1090,9 +1090,9 @@ the target device, it is important to understand packaging because the | |||
1090 | contents of the image are expressed in terms of packages and not | 1090 | contents of the image are expressed in terms of packages and not |
1091 | recipes. | 1091 | recipes. |
1092 | 1092 | ||
1093 | During the ```do_package`` <&YOCTO_DOCS_REF_URL;#ref-tasks-package>`__ | 1093 | During the :ref:`ref-tasks-package` |
1094 | task, files installed during the | 1094 | task, files installed during the |
1095 | ```do_install`` <&YOCTO_DOCS_REF_URL;#ref-tasks-install>`__ task are | 1095 | :ref:`ref-tasks-install` task are |
1096 | split into one main package, which is almost always named the same as | 1096 | split into one main package, which is almost always named the same as |
1097 | the recipe, and into several other packages. This separation exists | 1097 | the recipe, and into several other packages. This separation exists |
1098 | because not all of those installed files are useful in every image. For | 1098 | because not all of those installed files are useful in every image. For |
@@ -1105,14 +1105,14 @@ package splitting as well. | |||
1105 | After building a recipe, you can see where files have gone by looking in | 1105 | After building a recipe, you can see where files have gone by looking in |
1106 | the ``oe-workdir/packages-split`` directory, which contains a | 1106 | the ``oe-workdir/packages-split`` directory, which contains a |
1107 | subdirectory for each package. Apart from some advanced cases, the | 1107 | subdirectory for each package. Apart from some advanced cases, the |
1108 | ```PACKAGES`` <&YOCTO_DOCS_REF_URL;#var-PACKAGES>`__ and | 1108 | :term:`PACKAGES` and |
1109 | ```FILES`` <&YOCTO_DOCS_REF_URL;#var-FILES>`__ variables controls | 1109 | :term:`FILES` variables controls |
1110 | splitting. The ``PACKAGES`` variable lists all of the packages to be | 1110 | splitting. The ``PACKAGES`` variable lists all of the packages to be |
1111 | produced, while the ``FILES`` variable specifies which files to include | 1111 | produced, while the ``FILES`` variable specifies which files to include |
1112 | in each package by using an override to specify the package. For | 1112 | in each package by using an override to specify the package. For |
1113 | example, ``FILES_${PN}`` specifies the files to go into the main package | 1113 | example, ``FILES_${PN}`` specifies the files to go into the main package |
1114 | (i.e. the main package has the same name as the recipe and | 1114 | (i.e. the main package has the same name as the recipe and |
1115 | ``${``\ ```PN`` <&YOCTO_DOCS_REF_URL;#var-PN>`__\ ``}`` evaluates to the | 1115 | ``${``\ :term:`PN`\ ``}`` evaluates to the |
1116 | recipe name). The order of the ``PACKAGES`` value is significant. For | 1116 | recipe name). The order of the ``PACKAGES`` value is significant. For |
1117 | each installed file, the first package whose ``FILES`` value matches the | 1117 | each installed file, the first package whose ``FILES`` value matches the |
1118 | file is the package into which the file goes. Defaults exist for both | 1118 | file is the package into which the file goes. Defaults exist for both |
@@ -1190,7 +1190,7 @@ manually "pull down" the updates into the installed SDK. | |||
1190 | To update your installed SDK, use ``devtool`` as follows: $ devtool | 1190 | To update your installed SDK, use ``devtool`` as follows: $ devtool |
1191 | sdk-update The previous command assumes your SDK provider has set the | 1191 | sdk-update The previous command assumes your SDK provider has set the |
1192 | default update URL for you through the | 1192 | default update URL for you through the |
1193 | ```SDK_UPDATE_URL`` <&YOCTO_DOCS_REF_URL;#var-SDK_UPDATE_URL>`__ | 1193 | :term:`SDK_UPDATE_URL` |
1194 | variable as described in the "`Providing Updates to the Extensible SDK | 1194 | variable as described in the "`Providing Updates to the Extensible SDK |
1195 | After | 1195 | After |
1196 | Installation <#sdk-providing-updates-to-the-extensible-sdk-after-installation>`__" | 1196 | Installation <#sdk-providing-updates-to-the-extensible-sdk-after-installation>`__" |