From d5ae7d902a40f26a8c26f4c6d300226689738716 Mon Sep 17 00:00:00 2001 From: Brad Bishop Date: Thu, 14 Jun 2018 09:52:03 -0700 Subject: Sumo refresh Update external subtrees to latest Yocto sumo. Change-Id: I8364f32bef079841c6e57f1c587f4b1bedf62fef Signed-off-by: Brad Bishop --- poky/documentation/bsp-guide/bsp-guide.xml | 5 + poky/documentation/dev-manual/dev-manual.xml | 5 + poky/documentation/kernel-dev/kernel-dev.xml | 5 + .../sdk-installed-extensible-sdk-directory.png | Bin 42892 -> 66753 bytes .../sdk-installed-standard-sdk-directory.png | Bin 56096 -> 39099 bytes poky/documentation/mega-manual/mega-manual.xml | 5 + .../overview-manual/overview-manual.xml | 5 + poky/documentation/poky.ent | 14 +- .../profile-manual/profile-manual.xml | 5 + poky/documentation/ref-manual/ref-manual.xml | 5 + poky/documentation/ref-manual/ref-variables.xml | 134 ++++++++-- .../sdk-installed-extensible-sdk-directory.png | Bin 42892 -> 66753 bytes .../sdk-installed-standard-sdk-directory.png | Bin 56096 -> 39099 bytes .../sdk-manual/sdk-appendix-customizing.xml | 198 ++++++++------ .../documentation/sdk-manual/sdk-appendix-neon.xml | 297 ++++++++++++--------- .../sdk-manual/sdk-appendix-obtain.xml | 134 ++++++---- .../sdk-manual/sdk-eclipse-project.xml | 169 +++++++----- poky/documentation/sdk-manual/sdk-extensible.xml | 28 +- poky/documentation/sdk-manual/sdk-manual.xml | 5 + .../toaster-manual/toaster-manual.xml | 5 + poky/documentation/tools/mega-manual.sed | 48 ++-- 21 files changed, 686 insertions(+), 381 deletions(-) (limited to 'poky/documentation') diff --git a/poky/documentation/bsp-guide/bsp-guide.xml b/poky/documentation/bsp-guide/bsp-guide.xml index 7ca4c5d7d..7dc8326c7 100644 --- a/poky/documentation/bsp-guide/bsp-guide.xml +++ b/poky/documentation/bsp-guide/bsp-guide.xml @@ -121,6 +121,11 @@ May 2018 Released with the Yocto Project 2.5 Release. + + 2.5.1 + September 2018 + The initial document released with the Yocto Project 2.5.1 Release. + diff --git a/poky/documentation/dev-manual/dev-manual.xml b/poky/documentation/dev-manual/dev-manual.xml index 93a615c2a..0db938aea 100644 --- a/poky/documentation/dev-manual/dev-manual.xml +++ b/poky/documentation/dev-manual/dev-manual.xml @@ -106,6 +106,11 @@ May 2018 Released with the Yocto Project 2.5 Release. + + 2.5.1 + September 2018 + The initial document released with the Yocto Project 2.5.1 Release. + diff --git a/poky/documentation/kernel-dev/kernel-dev.xml b/poky/documentation/kernel-dev/kernel-dev.xml index 986c44044..52341fba8 100644 --- a/poky/documentation/kernel-dev/kernel-dev.xml +++ b/poky/documentation/kernel-dev/kernel-dev.xml @@ -91,6 +91,11 @@ May 2018 Released with the Yocto Project 2.5 Release. + + 2.5.1 + September 2018 + The initial document released with the Yocto Project 2.5.1 Release. + diff --git a/poky/documentation/mega-manual/figures/sdk-installed-extensible-sdk-directory.png b/poky/documentation/mega-manual/figures/sdk-installed-extensible-sdk-directory.png index 99e07ce6f..b71c8ad73 100644 Binary files a/poky/documentation/mega-manual/figures/sdk-installed-extensible-sdk-directory.png and b/poky/documentation/mega-manual/figures/sdk-installed-extensible-sdk-directory.png differ diff --git a/poky/documentation/mega-manual/figures/sdk-installed-standard-sdk-directory.png b/poky/documentation/mega-manual/figures/sdk-installed-standard-sdk-directory.png index d4af85020..45c0154b1 100644 Binary files a/poky/documentation/mega-manual/figures/sdk-installed-standard-sdk-directory.png and b/poky/documentation/mega-manual/figures/sdk-installed-standard-sdk-directory.png differ diff --git a/poky/documentation/mega-manual/mega-manual.xml b/poky/documentation/mega-manual/mega-manual.xml index 2c0943e26..ea35ce2ef 100644 --- a/poky/documentation/mega-manual/mega-manual.xml +++ b/poky/documentation/mega-manual/mega-manual.xml @@ -75,6 +75,11 @@ May 2018 Released with the Yocto Project 2.5 Release. + + 2.5.1 + September 2018 + The initial document released with the Yocto Project 2.5.1 Release. + diff --git a/poky/documentation/overview-manual/overview-manual.xml b/poky/documentation/overview-manual/overview-manual.xml index c283f9a37..4f581afd9 100644 --- a/poky/documentation/overview-manual/overview-manual.xml +++ b/poky/documentation/overview-manual/overview-manual.xml @@ -36,6 +36,11 @@ May 2018 The initial document released with the Yocto Project 2.5 Release. + + 2.5.1 + September 2018 + The initial document released with the Yocto Project 2.5.1 Release. + diff --git a/poky/documentation/poky.ent b/poky/documentation/poky.ent index 49b19008f..4f5646686 100644 --- a/poky/documentation/poky.ent +++ b/poky/documentation/poky.ent @@ -1,17 +1,17 @@ - - + + - + - + - + - - + + diff --git a/poky/documentation/profile-manual/profile-manual.xml b/poky/documentation/profile-manual/profile-manual.xml index b64875b8c..e329d4b68 100644 --- a/poky/documentation/profile-manual/profile-manual.xml +++ b/poky/documentation/profile-manual/profile-manual.xml @@ -91,6 +91,11 @@ May 2018 Released with the Yocto Project 2.5 Release. + + 2.5.1 + September 2018 + The initial document released with the Yocto Project 2.5.1 Release. + diff --git a/poky/documentation/ref-manual/ref-manual.xml b/poky/documentation/ref-manual/ref-manual.xml index 169a31e99..82c1d0bc3 100644 --- a/poky/documentation/ref-manual/ref-manual.xml +++ b/poky/documentation/ref-manual/ref-manual.xml @@ -122,6 +122,11 @@ May 2018 Released with the Yocto Project 2.5 Release. + + 2.5.1 + September 2018 + The initial document released with the Yocto Project 2.5.1 Release. + diff --git a/poky/documentation/ref-manual/ref-variables.xml b/poky/documentation/ref-manual/ref-variables.xml index 1c55a92d1..e88389647 100644 --- a/poky/documentation/ref-manual/ref-variables.xml +++ b/poky/documentation/ref-manual/ref-variables.xml @@ -3636,10 +3636,17 @@ The short name of the distribution. - This variable corresponds to a distribution - configuration file whose root name is the same as the - variable's argument and whose filename extension is - .conf. + For information on the long name of the distribution, see + the + DISTRO_NAME + variable. + + + + The DISTRO variable corresponds to a + distribution configuration file whose root name is the + same as the variable's argument and whose filename + extension is .conf. For example, the distribution configuration file for the Poky distribution is named poky.conf and resides in the @@ -3664,9 +3671,9 @@ The value for DISTRO must not contain spaces, and is typically all lower-case. - If the DISTRO variable is blank, a set - of default configurations are used, which are specified - within + If the DISTRO variable is blank, + a set of default configurations are used, which are + specified within meta/conf/distro/defaultsetup.conf also in the Source Directory. @@ -3931,6 +3938,46 @@ The long name of the distribution. + For information on the short name of the distribution, see + the + DISTRO + variable. + + + + The DISTRO_NAME variable corresponds + to a distribution configuration file whose root name is the + same as the variable's argument and whose filename + extension is .conf. + For example, the distribution configuration file for the + Poky distribution is named poky.conf + and resides in the + meta-poky/conf/distro directory of + the + Source Directory. + + + + Within that poky.conf file, the + DISTRO_NAME variable is set as + follows: + + DISTRO_NAME = "Poky (Yocto Project Reference Distro)" + + + + + Distribution configuration files are located in a + conf/distro directory within the + Metadata + that contains the distribution configuration. + + If the DISTRO_NAME variable is + blank, a set of default configurations are used, which + are specified within + meta/conf/distro/defaultsetup.conf + also in the Source Directory. + @@ -9917,7 +9964,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" execute at rootfs creation time rather than on the target but depends on a native tool in order to execute, you need to list the tools in - PACKAGE_WRITE_DEPENDS. + PACKAGE_WRITE_DEPS. @@ -12175,13 +12222,26 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" A list of classes to remove from the INHERIT value globally within the extensible SDK configuration. - The default value is "buildhistory icecc". + The + populate-sdk-ext + class sets the default value: + + SDK_INHERIT_BLACKLIST ?= "buildhistory icecc" + Some classes are not generally applicable within - the extensible SDK context and you can use this variable - to disable them. + the extensible SDK context. + You can use this variable to disable those classes. + + + + For additional information on how to customize the + extensible SDK's configuration, see the + "Configuring the Extensible SDK" + section in the Yocto Project Application Development and + the Extensible Software Development Kit (eSDK) manual. @@ -12193,12 +12253,40 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" - A list of variables not allowed through from the build - system configuration into the extensible SDK configuration. + A list of variables not allowed through from the + OpenEmbedded build system configuration into the extensible + SDK configuration. Usually, these are variables that are specific to the machine on which the build system is running and thus would be potentially problematic within the extensible SDK. + + + By default, + SDK_LOCAL_CONF_BLACKLIST is set in the + populate-sdk-ext + class and excludes the following variables: + + CONF_VERSION + BB_NUMBER_THREADS + BB_NUMBER_PARSE_THREADS + PARALLEL_MAKE + PRSERV_HOST + SSTATE_MIRRORS + DL_DIR + SSTATE_DIR + TMPDIR + BB_SERVER_TIMEOUT + + + + For additional information on how to customize the + extensible SDK's configuration, see the + "Configuring the Extensible SDK" + section in the Yocto Project Application Development and + the Extensible Software Development Kit (eSDK) manual. + + @@ -12209,8 +12297,16 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" - A list of variables allowed through from the build system - configuration into the extensible SDK configuration. + A list of variables allowed through from the OpenEmbedded + build system configuration into the extensible SDK + configuration. + By default, the list of variables is empty and is set in + the + populate-sdk-ext + class. + + + This list overrides the variables specified using the SDK_LOCAL_CONF_BLACKLIST variable as well as any variables identified by automatic @@ -12219,6 +12315,14 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" path and thus might not be valid on the system where the SDK is installed. + + + For additional information on how to customize the + extensible SDK's configuration, see the + "Configuring the Extensible SDK" + section in the Yocto Project Application Development and + the Extensible Software Development Kit (eSDK) manual. + diff --git a/poky/documentation/sdk-manual/figures/sdk-installed-extensible-sdk-directory.png b/poky/documentation/sdk-manual/figures/sdk-installed-extensible-sdk-directory.png index 99e07ce6f..b71c8ad73 100644 Binary files a/poky/documentation/sdk-manual/figures/sdk-installed-extensible-sdk-directory.png and b/poky/documentation/sdk-manual/figures/sdk-installed-extensible-sdk-directory.png differ diff --git a/poky/documentation/sdk-manual/figures/sdk-installed-standard-sdk-directory.png b/poky/documentation/sdk-manual/figures/sdk-installed-standard-sdk-directory.png index d4af85020..45c0154b1 100644 Binary files a/poky/documentation/sdk-manual/figures/sdk-installed-standard-sdk-directory.png and b/poky/documentation/sdk-manual/figures/sdk-installed-standard-sdk-directory.png differ diff --git a/poky/documentation/sdk-manual/sdk-appendix-customizing.xml b/poky/documentation/sdk-manual/sdk-appendix-customizing.xml index 5b56e738d..c3215e622 100644 --- a/poky/documentation/sdk-manual/sdk-appendix-customizing.xml +++ b/poky/documentation/sdk-manual/sdk-appendix-customizing.xml @@ -17,26 +17,31 @@ The extensible SDK primarily consists of a pre-configured copy of the OpenEmbedded build system from which it was produced. Thus, the SDK's configuration is derived using that build system and - the following filters, which the OpenEmbedded build system applies - against local.conf and - auto.conf if they are present: + the filters shown in the following list. + When these filters are present, the OpenEmbedded build system applies + them against local.conf and + auto.conf: Variables whose values start with "/" are excluded since the assumption is that those values are paths that are likely to - be specific to the build host. + be specific to the + build host. Variables listed in SDK_LOCAL_CONF_BLACKLIST are excluded. - The default value blacklists - CONF_VERSION, - BB_NUMBER_THREADS, - PARALLEL_MAKE, - PRSERV_HOST, - and - SSTATE_MIRRORS. + These variables are not allowed through from the OpenEmbedded + build system configuration into the extensible SDK + configuration. + Typically, these variables are specific to the machine on + which the build system is running and could be problematic + as part of the extensible SDK configuration. + + For a list of the variables excluded by default, see the + SDK_LOCAL_CONF_BLACKLIST + in the glossary of the Yocto Project Reference Manual. Variables listed in @@ -44,7 +49,7 @@ are included. Including a variable in the value of SDK_LOCAL_CONF_WHITELIST overrides either - of the above two conditions. + of the previous two filters. The default value is blank. @@ -54,7 +59,7 @@ SDK_INHERIT_BLACKLIST are disabled. Using SDK_INHERIT_BLACKLIST to disable - these classes is is the typical method to disable classes that + these classes is the typical method to disable classes that are problematic or unnecessary in the SDK context. The default value blacklists the buildhistory @@ -73,11 +78,13 @@ -
- Adjusting the Extensible SDK to Suit Your Build System Setup +
+ Adjusting the Extensible SDK to Suit Your Build Host's Setup - In most cases, the extensible SDK defaults should work. + In most cases, the extensible SDK defaults should work with your + build host's + setup. However, some cases exist for which you might consider making adjustments: @@ -88,33 +95,43 @@ variable and you do not need or want those classes enabled in the SDK, you can blacklist them by adding them to the SDK_INHERIT_BLACKLIST - variable. - The default value of SDK_INHERIT_BLACKLIST - is set using the "?=" operator. - Consequently, you will need to either set the complete value - using "=" or append the value using "_append". + variable as described in the fourth bullet of the previous + section. + + The default value of + SDK_INHERIT_BLACKLIST is set using + the "?=" operator. + Consequently, you will need to either define the entire + list by using the "=" operator, or you will need to append + a value using either "_append" or the "+=" operator. + You can learn more about these operators in the + "Basic Syntax" + section of the BitBake User Manual. + . If you have classes or recipes that add additional tasks to - the standard build flow (i.e. that execute as part of building - the recipe as opposed to needing to be called explicitly), then - you need to do one of the following: + the standard build flow (i.e. the tasks execute as the recipe + builds as opposed to being called explicitly), then you need + to do one of the following: - Ensure the tasks are shared state tasks (i.e. their - output is saved to and can be restored from the shared - state cache), or that the tasks are able to be - produced quickly from a task that is a shared state - task and add the task name to the value of + After ensuring the tasks are + shared state + tasks (i.e. the output of the task is saved to and + can be restored from the shared state cache) or + ensuring the tasks are able to be produced quickly from + a task that is a shared state task, add the task name + to the value of SDK_RECRDEP_TASKS. Disable the tasks if they are added by a class and you do not need the functionality the class provides in the extensible SDK. - To disable the tasks, add the class to - SDK_INHERIT_BLACKLIST as previously - described. + To disable the tasks, add the class to the + SDK_INHERIT_BLACKLIST variable + as described in the previous section. @@ -132,7 +149,7 @@ SDK_UPDATE_URL variable. For more information, see the - "Providing Updates After Installing the Extensible SDK" + "Providing Updates to the Extensible SDK After Installation" section. @@ -162,11 +179,12 @@
-
- Changing the Appearance of the Extensible SDK +
+ Changing the Extensible SDK Installer Title - You can change the title shown by the SDK installer by setting the + You can change the displayed title for the SDK installer by setting + the SDK_TITLE variable. By default, this title is derived from @@ -177,21 +195,37 @@ DISTRO variable. + + + The + populate_sdk_ext + class defines the default value of the SDK_TITLE + variable as follows: + + SDK_TITLE_task-populate-sdk-ext = "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} Extensible SDK" + +
-
- Providing Updates After Installing the Extensible SDK +
+ Providing Updates to the Extensible SDK After Installation When you make changes to your configuration or to the metadata and if you want those changes to be reflected in installed SDKs, you need - to perform additional steps to make it possible for those that use - the SDK to update their installations with the + to perform additional steps. + These steps make it possible for anyone using the installed SDKs to + update the installed SDKs by using the devtool sdk-update command: - Arrange to be created a directory that can be shared over - HTTP or HTTPS. + Create a directory that can be shared over HTTP or HTTPS. + You can do this by setting up a web server such as an + Apache HTTP Server + or + Nginx + server in the cloud to host the directory. + This directory must contain the published SDK. Set the @@ -199,7 +233,10 @@ variable to point to the corresponding HTTP or HTTPS URL. Setting this variable causes any SDK built to default to that URL and thus, the user does not have to pass the URL to the - devtool sdk-update command. + devtool sdk-update command as described + in the + "Applying Updates to an Installed Extensible SDK" + section. Build the extensible SDK normally (i.e., use the @@ -209,7 +246,7 @@ Publish the SDK using the following command: - $ oe-publish-sdk some_path/sdk-installer.sh path_to_shared/http_directory + $ oe-publish-sdk some_path/sdk-installer.sh path_to_shared_http_directory You must repeat this step each time you rebuild the SDK with changes that you want to make available through the @@ -219,11 +256,11 @@ - Completing the above steps allows users of the existing SDKs to - simply run devtool sdk-update to retrieve the - latest updates. + Completing the above steps allows users of the existing installed + SDKs to simply run devtool sdk-update to + retrieve and apply the latest updates. See the - "Updating the Extensible SDK" + "Applying Updates to an Installed Extensible SDK" section for further information.
@@ -232,27 +269,38 @@ Providing Additional Installable Extensible SDK Content - If you want the users of the extensible SDK you are building to be - able to add items to the SDK without needing to build the - items from source, you need to do a number of things: + If you want the users of an extensible SDK you build to be + able to add items to the SDK without requiring the users to build + the items from source, you need to do a number of things: Ensure the additional items you want the user to be able to - install are actually built. - You can ensure these items are built a number of different - ways: 1) Build them explicitly, perhaps using one or more - "meta" recipes that depend on lists of other recipes to keep - things tidy, or 2) Build the "world" target and set - EXCLUDE_FROM_WORLD_pn-recipename - for the recipes you do not want built. - See the - EXCLUDE_FROM_WORLD - variable for additional information. + install are already built: + + + Build the items explicitly. + You could use one or more "meta" recipes that depend + on lists of other recipes. + + + Build the "world" target and set + EXCLUDE_FROM_WORLD_pn-recipename + for the recipes you do not want built. + See the + EXCLUDE_FROM_WORLD + variable for additional information. + + Expose the sstate-cache directory produced by the build. - Typically, you expose this directory over HTTP or HTTPS. + Typically, you expose this directory by making it available + through an + Apache HTTP Server + or + Nginx + server. Set the appropriate configuration so that the produced SDK @@ -285,7 +333,7 @@ Alternatively, if you just want to set the SSTATE_MIRRORS variable's value for the SDK alone, create a - conf/sdk-extra.conf either in + conf/sdk-extra.conf file either in your Build Directory or within any layer and put your @@ -324,24 +372,24 @@ size, which downloads and installs quickly. You need to realize, though, that the minimal installer does not install any libraries or tools out of the box. - These must be installed either "on the fly" or through actions you - perform using devtool or explicitly with the - devtool sdk-install command. + These libraries and tools must be installed either "on the fly" or + through actions you perform using devtool or + explicitly with the devtool sdk-install command. - In most cases, when building a minimal SDK you will need to also enable + In most cases, when building a minimal SDK you need to also enable bringing in the information on a wider range of packages produced by the system. - This is particularly true so that devtool add - is able to effectively map dependencies it discovers in a source tree - to the appropriate recipes. - Also so that the devtool search command - is able to return useful results. + Requiring this wider range of information is particularly true + so that devtool add is able to effectively map + dependencies it discovers in a source tree to the appropriate recipes. + Additionally, the information enables the + devtool search command to return useful results. - To facilitate this wider range of information, you would additionally + To facilitate this wider range of information, you would need to set the following: SDK_INCLUDE_PKGDATA = "1" @@ -384,8 +432,8 @@ SDK_INCLUDE_TOOLCHAIN variable to "1". In particular, it is useful to include the toolchain when you - have set SDK_EXT_TYPE to - "minimal", which by default, excludes the toolchain. + have set SDK_EXT_TYPE to "minimal", which by + default, excludes the toolchain. Also, it is helpful if you are building a small SDK for use with an IDE, such as Eclipse, or some other tool where you do not want to take extra steps to install a diff --git a/poky/documentation/sdk-manual/sdk-appendix-neon.xml b/poky/documentation/sdk-manual/sdk-appendix-neon.xml index f648047ef..0fb92985a 100644 --- a/poky/documentation/sdk-manual/sdk-appendix-neon.xml +++ b/poky/documentation/sdk-manual/sdk-appendix-neon.xml @@ -14,8 +14,8 @@ from start to finish. For general information on using the Eclipse IDE and the Yocto Project Eclipse Plug-In, see the - "Developing Applications Using Eclipse" - Chapter. + "Application Development Workflow Using Eclipse" + section.
@@ -53,13 +53,18 @@ http://www.eclipse.org/neon/. Download the Tarball: - Click the "Download" button and then use the "Eclipse - IDE for C/C++ Developers" - appropriate for your development system. + Click the "Download" button and look for the + "Eclipse IDE for C/C++ Developers" Neon 3 Package. + Select the correct platform download link listed at + the right. + For example, click on "64-bit" next to Linux if your + build host is running a 64-bit Linux distribution. + Click through the process to save the file. Unpack the Tarball: - Move to a clean directory and unpack the tarball. - Here is an example: + Move to a directory and unpack the tarball. + The following commands unpack the tarball into the + home directory: $ cd ~ $ tar -xzvf ~/Downloads/eclipse-cpp-neon-3-linux-gtk-x86_64.tar.gz @@ -84,11 +89,22 @@ Follow these steps to configure the Neon Eclipse IDE. - - Depending on how you installed Eclipse and what you have - already done, some of the options will not appear. - If you cannot find an option as directed by the manual, - it has already been installed. + Notes + + + Depending on how you installed Eclipse and what + you have already done, some of the options do + not appear. + If you cannot find an option as directed by the + manual, it has already been installed. + + + If you want to see all options regardless of + whether they are installed or not, deselect the + "Hide items that are already installed" + check box. + + Be sure Eclipse is running and @@ -164,11 +180,11 @@ in the URL field and provide a meaningful name in the "Name" field. - Click "OK" to have the entry added - to the "Work with:" drop-down list. - - Select the entry for the plug-in - from the "Work with:" drop-down list. + + Click "OK" to have the entry automatically + populate the "Work with:" field and to have + the items for installation appear in the window + below. Check the boxes next to the following: @@ -196,8 +212,14 @@ To install the Neon Eclipse Yocto Plug-in from the latest source code, follow these steps: - Be sure your development system - has JDK 1.8+ + + Be sure your build host has JDK version 1.8 + or greater. + On a Linux build host you can determine the + version using the following command: + + $ java -version + install X11-related packages: @@ -211,18 +233,19 @@ $ git clone git://git.yoctoproject.org/eclipse-yocto - Use Git to checkout the correct - tag: + + Use Git to create the correct tag: $ cd ~/eclipse-yocto - $ git checkout neon/yocto-&DISTRO; + $ git checkout -b neon/&DISTRO_NAME_NO_CAP; remotes/origin/neon/&DISTRO_NAME_NO_CAP; This creates a local tag named - neon/yocto-&DISTRO; based on - the branch origin/neon-master. - This puts you in a detached HEAD state, which - is fine since you are only going to be building - and not developing. + neon/&DISTRO_NAME_NO_CAP; + based on the branch + origin/neon/&DISTRO_NAME_NO_CAP;. + You are put into a detached HEAD state, + which is fine since you are only going to + be building and not developing. Change to the scripts @@ -243,20 +266,22 @@ directory of the Git repository created earlier. - Run the build.sh + + Run the build.sh script as directed. - Be sure to provide the tag name, documentation - branch, and a release name. - - Following is an example: + Be sure to provide the tag name, + documentation branch, and a release name. + + Following is an example: - $ ECLIPSE_HOME=/home/scottrif/eclipse-yocto/scripts/eclipse ./build.sh -l neon/yocto-&DISTRO; master yocto-&DISTRO; 2>&1 | tee build.log + $ ECLIPSE_HOME=/home/scottrif/eclipse-yocto/scripts/eclipse ./build.sh -l neon/&DISTRO_NAME_NO_CAP; master yocto-&DISTRO; 2>&1 | tee build.log - The previous example command adds the tag you - need for neon/yocto-&DISTRO; - to HEAD, then tells the - build script to use the local (-l) Git checkout - for the build. + The previous example command adds the tag + you need for + neon/&DISTRO_NAME_NO_CAP; + to HEAD, then tells + the build script to use the local (-l) Git + checkout for the build. After running the script, the file org.yocto.sdk-release-date-archive.zip is in the current directory. @@ -310,7 +335,7 @@
- Configuring the Neon Eclipse Yocto Plug-in + Configuring the Neon Eclipse Yocto Plug-In Configuring the Neon Eclipse Yocto Plug-in involves setting the @@ -324,14 +349,16 @@ To start, you need to do the following from within the Eclipse IDE: - - Choose "Preferences" from the + + + Choose "Preferences" from the "Window" menu to display the Preferences Dialog. - Click "Yocto Project SDK" to display + + Click "Yocto Project SDK" to display the configuration screen. - + The following sub-sections describe how to configure the the plug-in. @@ -354,15 +381,15 @@ the sysroot location, and select the target architecture. - Selecting the Toolchain Type: - Choose between - Standalone pre-built toolchain + + Selecting the Toolchain Type: + Choose between "Standalone pre-built toolchain" and - Build system derived toolchain - for Cross Compiler Options. + "Build system derived toolchain" for Cross Compiler + Options. - - Standalone Pre-built Toolchain: + + Standalone Pre-built Toolchain: Select this type when you are using a stand-alone cross-toolchain. For example, suppose you are an @@ -376,24 +403,25 @@ and installed a pre-built toolchain for an existing image. - - Build System Derived Toolchain: + + Build System Derived Toolchain: Select this type if you built the toolchain as part of the Build Directory. - When you select - Build system derived toolchain, - you are using the toolchain built and - bundled inside the Build Directory. + When you select "Build system derived + toolchain", you are using the toolchain + built and bundled inside the Build + Directory. For example, suppose you created a suitable image using the steps in the wiki. - In this situation, you would select the - Build system derived toolchain. + In this situation, you would select + "Build system derived toolchain". - Specify the Toolchain Root Location: + + Specify the Toolchain Root Location: If you are using a stand-alone pre-built toolchain, you should be pointing to where it is installed (e.g. @@ -402,10 +430,10 @@ "Installing the SDK" section for information about how the SDK is installed. + If you are using a build system derived toolchain, the path you provide for the - Toolchain Root Location - field is the + "Toolchain Root Location" field is the Build Directory from which you run the bitbake command (e.g @@ -414,10 +442,12 @@ "Building an SDK Installer" section. - Specify Sysroot Location: + + Specify Sysroot Location: This location is where the root filesystem for the target hardware resides. + This location depends on where you separately extracted and installed the target filesystem when you either built @@ -438,17 +468,18 @@ and you would browse to and select that directory (e.g. /home/scottrif/build/MY_QEMU_ROOTFS). + For more information on how to install the toolchain and on how to extract and install the sysroot filesystem, see the "Building an SDK Installer" section. - Select the Target Architecture: + + Select the Target Architecture: The target architecture is the type of hardware you are going to use or emulate. - Use the pull-down - Target Architecture menu + Use the pull-down "Target Architecture" menu to make your selection. The pull-down menu should have the supported architectures. @@ -473,16 +504,17 @@ emulator, or you can choose to run your image on actual hardware. - QEMU: + + QEMU: Select this option if you will be using the QEMU emulator. If you are using the emulator, you also need to locate the kernel and specify any custom options. - If you selected the - Build system derived toolchain, - the target kernel you built will be located in - the + + If you selected the Build system derived + toolchain, the target kernel you built will be + located in the Build Directory in tmp/deploy/images/machine @@ -494,10 +526,12 @@ followed by the image (e.g. /home/scottrif/poky/build/tmp/deploy/images/qemux86/bzImage-qemux86.bin). + If you selected the standalone pre-built toolchain, the pre-built image you downloaded is located in the directory you specified when you downloaded the image. + Most custom options are for advanced QEMU users to further customize their QEMU instance. These options are specified between paired @@ -514,16 +548,16 @@ The following is an example: serial ‘<-m 256 -full-screen>’ - - + Regardless of the mode, Sysroot is already defined as part of the Cross-Compiler Options - configuration in the - Sysroot Location: field. + configuration in the "Sysroot Location:" field. - External HW: + + External HW: Select this option if you will be using actual - hardware. + hardware. + @@ -558,31 +592,37 @@ To create a project based on a Yocto template and then display the source code, follow these steps: - Select "C Project" from the "File -> New" menu. + + Select "C Project" from the "File -> New" menu. - Expand Yocto Project SDK Autotools Project. + + Expand "Yocto Project SDK Autotools Project". - Select Hello World ANSI C Autotools Projects. + + Select "Hello World ANSI C Autotools Projects". This is an Autotools-based project based on a Yocto template. - Put a name in the Project name: - field. + + Put a name in the "Project name:" field. Do not use hyphens as part of the name - (e.g. hello). + (e.g. "hello"). - Click "Next". + + Click "Next". - Add appropriate information in the various - fields. + + Add appropriate information in the various fields. - Click "Finish". + + Click "Finish". - If the "open perspective" prompt appears, + + If the "open perspective" prompt appears, click "Yes" so that you are in the C/C++ perspective. - The left-hand navigation pane shows your - project. + + The left-hand navigation pane shows your project. You can display your source by double clicking the project's source file. @@ -600,7 +640,8 @@ You can override these settings for a given project by following these steps: - Select "Yocto Project Settings" from + + Select "Yocto Project Settings" from the "Project -> Properties" menu. This selection brings up the Yocto Project Settings Dialog and allows you to make changes specific to an @@ -613,22 +654,19 @@ The Yocto Project Settings Dialog allows you to override those default settings for a given project. - Make or verify your configurations for the - project and click "OK". + + Make or verify your configurations for the project and + click "OK". - Right-click in the navigation pane and - select "Reconfigure Project" from the pop-up menu. + + Right-click in the navigation pane and select + "Reconfigure Project" from the pop-up menu. This selection reconfigures the project by running - autogen.sh in the workspace for - your project. - The script also runs libtoolize, - aclocal, - autoconf, - autoheader, - automake --a, and - ./configure. - Click on the "Console" tab beneath your source code to - see the results of reconfiguring your project. + Autotools GNU utility programs + such as Autoconf, Automake, and so forth in the + workspace for your project. + Click on the "Console" tab beneath your source code + to see the results of reconfiguring your project. @@ -656,8 +694,7 @@ Select the project. - Select "Folder" from the - File > New menu. + Select "Folder" from the "File > New" menu. In the "New Folder" Dialog, select "Link to alternate @@ -782,54 +819,66 @@ exit out of or close that shell). - Select "Debug Configurations..." from the + + Select "Debug Configurations..." from the "Run" menu. - In the left area, expand - C/C++Remote Application. + + In the left area, expand + "C/C++Remote Application". - Locate your project and select it to bring + + Locate your project and select it to bring up a new tabbed view in the Debug Configurations Dialog. - Click on the "Debugger" tab to see the + + Click on the "Debugger" tab to see the cross-tool debugger you are using. Be sure to change to the debugger perspective in Eclipse. - Click on the "Main" tab. + + Click on the "Main" tab. Create a new connection to the QEMU instance by clicking on "new". - Select SSH, which means + + Select "SSH", which means Secure Socket Shell. Optionally, you can select a TCF connection instead. - Click "Next". + + Click "Next". - Clear out the "Connection name" field and + + Clear out the "Connection name" field and enter any name you want for the connection. - Put the IP address for the connection in + + Put the IP address for the connection in the "Host" field. - For QEMU, the default is 192.168.7.2. + For QEMU, the default is "192.168.7.2". However, if a previous QEMU session did not exit cleanly, the IP address increments (e.g. - 192.168.7.3). + "192.168.7.3"). You can find the IP address for the current QEMU session by looking in the xterm that opens when you launch QEMU. - Enter root, which + + Enter "root", which is the default for QEMU, for the "User" field. Be sure to leave the password field empty. Click "Finish" to close the New Connections Dialog. - If necessary, use the drop-down menu now in the + + If necessary, use the drop-down menu now in the "Connection" field and pick the IP Address you entered. - Assuming you are connecting as the root user, + + Assuming you are connecting as the root user, which is the default for QEMU x86-64 SDK images provided by the Yocto Project, in the "Remote Absolute File Path for C/C++ Application" field, browse to @@ -874,9 +923,11 @@ Be sure you change to the "Debug" perspective in Eclipse. - Click "Debug" + + Click "Debug" - Accept the debug perspective. + + Accept the debug perspective. diff --git a/poky/documentation/sdk-manual/sdk-appendix-obtain.xml b/poky/documentation/sdk-manual/sdk-appendix-obtain.xml index aa06358a0..c608e6f54 100644 --- a/poky/documentation/sdk-manual/sdk-appendix-obtain.xml +++ b/poky/documentation/sdk-manual/sdk-appendix-obtain.xml @@ -25,32 +25,33 @@ Go to - Open the Folder for Your Development System: - Open the folder that matches your host development system + Open the Folder for Your Build Host: + Open the folder that matches your + build host (i.e. i686 for 32-bit machines or x86_64 for 64-bit machines). Locate and Download the SDK Installer: You need to find and download the installer appropriate for - your development system, target hardware, and image type. + your build host, target hardware, and image type. The installer files (*.sh) follow this naming convention: - poky-eglibc-host_system-core-image-type-arch-toolchain-ext-release.sh + poky-glibc-host_system-core-image-type-arch-toolchain[-ext]-release.sh Where: host_system is a string representing your development system: - i686 or x86_64. + "i686" or "x86_64" - type is a string representing either a "sato" or "minimal" - image. + type is a string representing the image: + "sato" or "minimal" arch is a string representing the target architecture: - aarch64, armv5e, core2-64, coretexa8hf-neon, i586, mips3242, - mips64, or ppc7400. + "aarch64", "armv5e", "core2-64", "coretexa8hf-neon", "i586", "mips32r2", + "mips64", or "ppc7400" release is the version of Yocto Project. @@ -65,10 +66,10 @@ libraries appropriate for developing against those images. - For example, if your host development system is a - 64-bit x86 system and you are need an extended SDK for a - 64-bit core2 target, go into the x86_64 - folder and download the following installer: + For example, if your build host is a 64-bit x86 system + and you need an extended SDK for a 64-bit core2 target, go + into the x86_64 folder and download the + following installer: poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh @@ -97,7 +98,7 @@ Building an SDK Installer - As an alternative to locating and downloading a SDK installer, + As an alternative to locating and downloading an SDK installer, you can build the SDK installer. Follow these steps: @@ -138,8 +139,7 @@ Among other things, the script creates the Build Directory, which is build in this case - and is located in the - Source Directory. + and is located in the Source Directory. After the script runs, your current working directory is set to the build directory. @@ -148,17 +148,31 @@ Check to be sure that your MACHINE variable in the local.conf file in your - Build Directory - matches the architecture for which you are building. + Build Directory matches the architecture for which you are + building. Make Sure Your SDK Machine is Correctly Set: If you are building a toolchain designed to run on an architecture that differs from your current development host - machine (i.e. the build machine), be sure that the + machine (i.e. the build host), be sure that the SDKMACHINE variable in the local.conf file in your Build Directory is correctly set. + + If you are building an SDK installer for the Extensible + SDK, the SDKMACHINE value must be + set for the architecture of the machine you are using to + build the installer. + If SDKMACHINE is not set appropriately, + the build fails and provides an error message similar to + the following: + + The extensible SDK can currently only be built for the same architecture as the machine being built on - SDK_ARCH is + set to i686 (likely via setting SDKMACHINE) which is different from the architecture of the build machine (x86_64). + Unable to continue. + + Build the SDK Installer: @@ -174,7 +188,7 @@ $ bitbake image -c populate_sdk_ext - These commands result in a SDK installer that contains the + These commands produce an SDK installer that contains the sysroot that matches your target root filesystem. When the bitbake command completes, @@ -183,16 +197,18 @@ Notes - By default, this toolchain does not build static - binaries. + By default, the previous BitBake command does not + build static binaries. If you want to use the toolchain to build these types of libraries, you need to be sure your SDK has the appropriate static development libraries. Use the TOOLCHAIN_TARGET_TASK variable inside your local.conf - file to install the appropriate library packages - in the SDK. + file before building the SDK installer. + Doing so ensures that the eventual SDK installation + process installs the appropriate library packages + as part of the SDK. Following is an example using libc static development libraries: @@ -262,32 +278,40 @@ Root Filesystem Image File: You need to find and download the root filesystem image file that is appropriate for your target system. - These files are kept in the + These files are kept in machine-specific folders in the Index of Releases in the "machines" directory. - The "machines" directory contains tarballs - (*.tar.bz2) for supported machines. - The directory also contains flattened root filesystem + The machine-specific folders of the "machines" directory + contain tarballs (*.tar.bz2) for supported + machines. + These directories also contain flattened root filesystem image files (*.ext4), which you can use with QEMU directly. The pre-built root filesystem image files follow these naming conventions: + core-image-profile-arch.tar.bz2 Where: profile is the filesystem image's profile: - lsb, lsb-dev, lsb-sdk, lsb-qt3, minimal, minimal-dev, sato, - sato-dev, sato-sdk, minimal-initramfs, or sdk-ptest. For - information on these types of image profiles, see the - "Images" chapter in the Yocto Project Reference Manual. + lsb, lsb-dev, lsb-sdk, minimal, minimal-dev, minimal-initramfs, + sato, sato-dev, sato-sdk, sato-sdk-ptest. For information on + these types of image profiles, see the "Images" chapter in + the Yocto Project Reference Manual. arch is a string representing the target architecture: - beaglebone, edgerouter, genericx86, genericx86-64, mpc8315e-rdb, - qemuarm, qemuarm64, qemumips, qemumips64, qemuppc, qemux86, or - qemux86-64. + beaglebone-yocto, beaglebone-yocto-lsb, edgerouter, edgerouter-lsb, + genericx86, genericx86-64, genericx86-64-lsb, genericx86-lsb, + mpc8315e-rdb, mpc8315e-rdb-lsb, and qemu*. + + + date_time is a date and time stamp. +--> The root filesystems provided by the Yocto Project are based @@ -295,26 +319,28 @@ core-image-minimal images. - For example, if your target hardware system is a - BeagleBone board and your image is a - core-image-minimal image, you need - to download the following root filesystem image file: + For example, if you plan on using a BeagleBone device + as your target hardware and your image is a + core-image-sato-sdk + image, you can download the following file: - core-image-minimal-beaglebone.tar.bz2 + core-image-sato-sdk-beaglebone-yocto.tar.bz2 Initialize the Cross-Development Environment: - You must source - the cross-development environment setup script to establish - necessary environment variables. + You must source the cross-development + environment setup script to establish necessary environment + variables. This script is located in the top-level directory in which you installed the toolchain (e.g. poky_sdk). - Following is an example for the Core2 64-bit - architecture: + Following is an example based on the toolchain installed + in the + "Locating Pre-Built SDK Installers" + section: $ source ~/poky_sdk/environment-setup-core2-64-poky-linux @@ -331,10 +357,10 @@ This command extracts the root filesystem into the core2-64-sato directory: - $ runqemu-extract-sdk ~/Downloads/core-image-sato-core2-64.tar.bz2 ~/core2-64-sato + $ runqemu-extract-sdk ~/Downloads/core-image-sato-sdk-beaglebone-yocto.tar.bz2 ~/beaglebone-sato You could now point to the target sysroot at - core2-64-sato. + beablebone-sato. @@ -350,7 +376,7 @@ - + @@ -391,7 +417,7 @@ - + @@ -406,8 +432,8 @@ Of note in the directory structure are an environment setup script for the SDK, a configuration file for the target, a version file for - the target, and a log file for the OpenEmbedded build system - preparation script run by the installer. + the target, and log files for the OpenEmbedded build system + preparation script run by the installer and BitBake. @@ -415,11 +441,9 @@ portions of the file or directory name. For example, install_dir is the directory where the SDK - is installed, which is poky_sdk by default. + is installed, which is poky_sdk by default, and target represents the target - architecture (e.g. i586) and - host represents the development system's - architecture (e.g. x86_64). + architecture (e.g. i586).
diff --git a/poky/documentation/sdk-manual/sdk-eclipse-project.xml b/poky/documentation/sdk-manual/sdk-eclipse-project.xml index 3eb85e8ab..f8a586f54 100644 --- a/poky/documentation/sdk-manual/sdk-eclipse-project.xml +++ b/poky/documentation/sdk-manual/sdk-eclipse-project.xml @@ -12,15 +12,34 @@ application all from within Eclipse. This chapter describes general workflow using the SDK and Eclipse and how to configure and set up Eclipse. + Notes + + + This chapter assumes development of applications on top of + an image prepared using the Yocto Project. + As such, inclusion of a pre-built image or the building of + an image is included in the workflow. + + + The chapter also assumes development on a build host that + is set up to use the Yocto Project. + Realize that you can easily use Eclipse and the Yocto + Project plug-in to develop an application for any number + of images developed and tested on different machines. + + + -
- Workflow Using <trademark class='trade'>Eclipse</trademark> +
+ Application Development Workflow Using <trademark class='trade'>Eclipse</trademark> - The following figure and supporting list summarize the + The following figure and supporting list summarize a general workflow for application development that uses the SDK within the Eclipse IDE. + The application developed runs on top of an image created using + the Yocto Project. @@ -32,22 +51,29 @@ Prepare the Host System for the Yocto Project: + Because this example workflow assumes development on a + system set up to use the Yocto Project, you need to be + sure your + build host + can use the Yocto Project. See the - "Supported Linux Distributions" - and - "Required Packages for the Host Development System" - sections both in the Yocto Project Reference Manual for - requirements. - In particular, be sure your host system has the - xterm package installed. + "Preparing a Build Host" + section in the Yocto Project Development Tasks Manual for + information on how to set up your build host. + + Be sure you install the "xterm" package, which is a + graphical and Eclipse plug-in extra + needed by Eclipse. + - Secure the Yocto Project Kernel Target - Image: - You must have a target kernel image that has been built - using the OpenEmbedded build system. - Depending on whether the Yocto Project has a - pre-built image that matches your target architecture + Secure the Yocto Project Kernel Target Image: + This example workflow assumes application development on + top of an image built using the Yocto Project. + Depending on whether you are using a pre-built image + that matches your target architecture or you are using an + image you build using the + OpenEmbedded Build System and where you are going to run the image while you develop your application (QEMU or real hardware), the area from which you get the image differs. @@ -78,6 +104,10 @@ "Using devtool to Patch the Kernel" section in the Yocto Project Linux Kernel Development Manual for an example. + You can also see the + "Making a Suitable Qemux86 Image" + wiki for steps needed to build an image suitable + for QEMU and for debugging within the Eclipse IDE. @@ -91,10 +121,10 @@ section. - Secure the Target Root Filesystem - and the Cross-Development Toolchain: + Secure the Target Root Filesystem and the Cross-Development Toolchain: You need to find and download the appropriate root filesystem and the cross-development toolchain. + You can find the tarballs for the root filesystem in the same area used for the kernel image. Depending on the type of image you are running, the @@ -102,6 +132,7 @@ For example, if you are developing an application that runs on an image that supports Sato, you need to get a root filesystem that supports Sato. + You can find the cross-development toolchains at toolchains. Be sure to get the correct toolchain for your @@ -124,8 +155,7 @@ Create and Build Your Application: - At this point, you need to have source files for your - application. + You need to have source files for your application. Once you have the files, you can use the Eclipse IDE to import them and build the project. @@ -270,6 +300,17 @@ "Launch" button. You should see the Eclipse welcome page from which can click "workbench" to enter your workspace. + + The executable for Eclipse is located in the + eclipse/cpp-oxygen/eclipse + folder. + To launch Eclipse outside of the installation + process, simply execute that binary. + Here is an example: + + $ ~/eclipse/cpp-oxygen/eclipse/eclipse + + @@ -284,13 +325,13 @@ Depending on how you installed Eclipse and what - you have already done, some of the options will + you have already done, some of the options do not appear. If you cannot find an option as directed by the manual, it has already been installed. - If you want to see all items regardless of + If you want to see all options regardless of whether they are installed or not, deselect the "Hide items that are already installed" check box. @@ -555,7 +596,7 @@
- Configuring the Oxygen Eclipse Yocto Plug-in + Configuring the Oxygen Eclipse Yocto Plug-In Configuring the Oxygen Eclipse Yocto Plug-in involves @@ -604,18 +645,13 @@ architecture. - Selecting the Toolchain - Type: - Choose between - Standalone pre-built toolchain - and - Build system derived toolchain - for Cross Compiler Options. + Selecting the Toolchain Type: + Choose between "Standalone pre-built toolchain" + and "Build system derived toolchain" for + Cross Compiler Options. - - Standalone Pre-built Toolchain: - + Standalone Pre-built Toolchain: Select this type when you are using a stand-alone cross-toolchain. For example, suppose you are an @@ -630,29 +666,24 @@ for an existing image. - - Build System Derived Toolchain: - + Build System Derived Toolchain: Select this type if you built the toolchain as part of the Build Directory. - When you select - Build system derived toolchain, - you are using the toolchain built - and bundled inside the Build + When you select "Build system derived + toolchain", you are using the toolchain + built and bundled inside the Build Directory. For example, suppose you created a suitable image using the steps in the wiki. In this situation, you would select - the - Build system derived toolchain. + "Build system derived toolchain". - Specify the Toolchain Root - Location: + Specify the Toolchain Root Location: If you are using a stand-alone pre-built toolchain, you should be pointing to where it is installed (e.g. @@ -661,11 +692,10 @@ "Installing the SDK" section for information about how the SDK is installed. + If you are using a build system derived toolchain, the path you provide for - the - Toolchain Root Location - field is the + the "Toolchain Root Location" field is the Build Directory from which you run the bitbake command (e.g @@ -676,11 +706,11 @@ section. - Specify Sysroot Location: - + Specify Sysroot Location: This location is where the root filesystem for the target hardware resides. + This location depends on where you separately extracted and installed the target filesystem when you either built @@ -702,6 +732,7 @@ directory (e.g. /home/scottrif/poky/build/MY_QEMU_ROOTFS). + For more information on how to install the toolchain and on how to extract and install the sysroot filesystem, see the @@ -709,12 +740,10 @@ section. - Select the Target Architecture: - + Select the Target Architecture: The target architecture is the type of hardware you are going to use or emulate. - Use the pull-down - Target Architecture + Use the pull-down "Target Architecture" menu to make your selection. The pull-down menu should have the supported architectures. @@ -747,10 +776,10 @@ If you are using the emulator, you also need to locate the kernel and specify any custom options. - If you selected the - Build system derived toolchain, - the target kernel you built will be located - in the + + If you selected the Build system derived + toolchain, the target kernel you built will be + located in the Build Directory in tmp/deploy/images/machine @@ -762,11 +791,13 @@ Directory path followed by the image (e.g. /home/scottrif/poky/build/tmp/deploy/images/qemux86/bzImage-qemux86.bin). + If you selected the standalone pre-built toolchain, the pre-built image you downloaded is located in the directory you specified when you downloaded the image. + Most custom options are for advanced QEMU users to further customize their QEMU instance. @@ -785,18 +816,17 @@ The following is an example: serial ‘<-m 256 -full-screen>’ - - + Regardless of the mode, Sysroot is already defined as part of the Cross-Compiler - Options configuration in the - Sysroot Location: - field. + Options configuration in the "Sysroot + Location:" field. External HW: Select this option if you will be using - actual hardware. + actual hardware. + @@ -849,7 +879,7 @@ Put a name in the "Project name:" field. Do not use hyphens as part of the name - (e.g. hello). + (e.g. "hello"). Click "Next". @@ -1080,7 +1110,7 @@ In the left area, expand - C/C++Remote Application. + "C/C++Remote Application". Locate your project and select it to bring @@ -1099,7 +1129,7 @@ Create a new connection to the QEMU instance by clicking on "new". - Select SSH, which + Select "SSH", which means Secure Socket Shell and then click "OK". Optionally, you can select a TCF connection instead. @@ -1111,11 +1141,10 @@ Put the IP address for the connection in the "Host" field. - For QEMU, the default is - 192.168.7.2. + For QEMU, the default is "192.168.7.2". However, if a previous QEMU session did not exit cleanly, the IP address increments (e.g. - 192.168.7.3). + "192.168.7.3"). You can find the IP address for the current QEMU session by looking in the xterm that @@ -1123,7 +1152,7 @@ - Enter root, which + Enter "root", which is the default for QEMU, for the "User" field. Be sure to leave the password field empty. diff --git a/poky/documentation/sdk-manual/sdk-extensible.xml b/poky/documentation/sdk-manual/sdk-extensible.xml index 5215a9d09..09f06088d 100644 --- a/poky/documentation/sdk-manual/sdk-extensible.xml +++ b/poky/documentation/sdk-manual/sdk-extensible.xml @@ -1715,31 +1715,35 @@
-
- Updating the Extensible SDK +
+ Applying Updates to an Installed Extensible SDK - If you are working with an extensible SDK that gets occasionally - updated (e.g. typically when that SDK has been provided to you by - another party), then you will need to manually pull down those - updates to your installed SDK. + If you are working with an installed extensible SDK that gets + occasionally updated (e.g. a third-party SDK), then you will need + to manually "pull down" the updates into the installed SDK. - To update your installed SDK, run the following: + To update your installed SDK, use devtool as + follows: $ devtool sdk-update The previous command assumes your SDK provider has set the default - update URL for you. - If that URL has not been set, you need to specify it yourself as - follows: + update URL for you through the + SDK_UPDATE_URL + variable as described in the + "Providing Updates to the Extensible SDK After Installation" + section. + If the SDK provider has not set that default URL, you need to + specify it yourself in the command as follows: $ devtool sdk-update path_to_update_directory - The URL needs to point specifically to a published SDK and not an - SDK installer that you would download and install. + The URL needs to point specifically to a published SDK and + not to an SDK installer that you would download and install.
diff --git a/poky/documentation/sdk-manual/sdk-manual.xml b/poky/documentation/sdk-manual/sdk-manual.xml index e858b9b1c..60db9dc8e 100644 --- a/poky/documentation/sdk-manual/sdk-manual.xml +++ b/poky/documentation/sdk-manual/sdk-manual.xml @@ -56,6 +56,11 @@ May 2018 Released with the Yocto Project 2.5 Release. + + 2.5.1 + September 2018 + The initial document released with the Yocto Project 2.5.1 Release. + diff --git a/poky/documentation/toaster-manual/toaster-manual.xml b/poky/documentation/toaster-manual/toaster-manual.xml index 188874488..4a9a65720 100644 --- a/poky/documentation/toaster-manual/toaster-manual.xml +++ b/poky/documentation/toaster-manual/toaster-manual.xml @@ -66,6 +66,11 @@ May 2018 Released with the Yocto Project 2.5 Release. + + 2.5.1 + September 2018 + The initial document released with the Yocto Project 2.5.1 Release. + diff --git a/poky/documentation/tools/mega-manual.sed b/poky/documentation/tools/mega-manual.sed index 64fa4d219..d0c667f3f 100644 --- a/poky/documentation/tools/mega-manual.sed +++ b/poky/documentation/tools/mega-manual.sed @@ -2,39 +2,39 @@ # This style is for manual folders like "yocto-project-qs" and "poky-ref-manual". # This is the old way that did it. Can't do that now that we have "bitbake-user-manual" strings # in the mega-manual. -# s@"ulink" href="http://www.yoctoproject.org/docs/2.5/[a-z]*-[a-z]*-[a-z]*/[a-z]*-[a-z]*-[a-z]*.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5/yocto-project-qs/yocto-project-qs.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5/poky-ref-manual/poky-ref-manual.html#@"link" href="#@g +# s@"ulink" href="http://www.yoctoproject.org/docs/2.5.1/[a-z]*-[a-z]*-[a-z]*/[a-z]*-[a-z]*-[a-z]*.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.5.1/yocto-project-qs/yocto-project-qs.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.5.1/poky-ref-manual/poky-ref-manual.html#@"link" href="#@g # Processes all other manuals (- style) except for the BitBake User Manual because # it is not included in the mega-manual. # This style is for manual folders that use two word, which is the standard now (e.g. "ref-manual"). # This was the one-liner that worked before we introduced the BitBake User Manual, which is # not in the mega-manual. -# s@"ulink" href="http://www.yoctoproject.org/docs/2.5/[a-z]*-[a-z]*/[a-z]*-[a-z]*.html#@"link" href="#@g +# s@"ulink" href="http://www.yoctoproject.org/docs/2.5.1/[a-z]*-[a-z]*/[a-z]*-[a-z]*.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5/sdk-manual/sdk-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5/bsp-guide/bsp-guide.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5/overview-manual/overview-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5/brief-yoctoprojectqs/brief-yoctoprojectqs.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5/kernel-dev/kernel-dev.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5/profile-manual/profile-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#@"link" href="#@g -s@"ulink" href="http://www.yoctoproject.org/docs/2.5/toaster-manual/toaster-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.5.1/sdk-manual/sdk-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.5.1/bsp-guide/bsp-guide.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.5.1/dev-manual/dev-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.5.1/overview-manual/overview-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.5.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.5.1/profile-manual/profile-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.5.1/ref-manual/ref-manual.html#@"link" href="#@g +s@"ulink" href="http://www.yoctoproject.org/docs/2.5.1/toaster-manual/toaster-manual.html#@"link" href="#@g # Process cases where just an external manual is referenced without an id anchor -s@Yocto Project Quick Build@Yocto Project Quick Build@g -s@Yocto Project Quick Start@Yocto Project Quick Start@g -s@Yocto Project Development Tasks Manual@Yocto Project Development Tasks Manual@g -s@Yocto Project Overview and Concepts Manual@Yocto project Overview and Concepts Manual@g -s@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@g -s@Yocto Project Board Support Package (BSP) Developer's Guide@Yocto Project Board Support Package (BSP) Developer's Guide@g -s@Yocto Project Profiling and Tracing Manual@Yocto Project Profiling and Tracing Manual@g -s@Yocto Project Linux Kernel Development Manual@Yocto Project Linux Kernel Development Manual@g -s@Yocto Project Reference Manual@Yocto Project Reference Manual@g -s@Toaster User Manual@Toaster User Manual@g +s@Yocto Project Quick Build@Yocto Project Quick Build@g +s@Yocto Project Quick Start@Yocto Project Quick Start@g +s@Yocto Project Development Tasks Manual@Yocto Project Development Tasks Manual@g +s@Yocto Project Overview and Concepts Manual@Yocto project Overview and Concepts Manual@g +s@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@g +s@Yocto Project Board Support Package (BSP) Developer's Guide@Yocto Project Board Support Package (BSP) Developer's Guide@g +s@Yocto Project Profiling and Tracing Manual@Yocto Project Profiling and Tracing Manual@g +s@Yocto Project Linux Kernel Development Manual@Yocto Project Linux Kernel Development Manual@g +s@Yocto Project Reference Manual@Yocto Project Reference Manual@g +s@Toaster User Manual@Toaster User Manual@g # Process a single, rouge occurrence of a linked reference to the Mega-Manual. -s@Yocto Project Mega-Manual@Yocto Project Mega-Manual@g +s@Yocto Project Mega-Manual@Yocto Project Mega-Manual@g -- cgit v1.2.1