diff options
| -rw-r--r-- | documentation/poky-ref-manual/development.xml | 519 |
1 files changed, 274 insertions, 245 deletions
diff --git a/documentation/poky-ref-manual/development.xml b/documentation/poky-ref-manual/development.xml index 67badce777..0eda1e9a88 100644 --- a/documentation/poky-ref-manual/development.xml +++ b/documentation/poky-ref-manual/development.xml @@ -14,22 +14,26 @@ <section id="platdev-appdev-external-sdk"> <title>External Development Using the Poky SDK</title> <para> - The meta-toolchain and meta-toolchain-sdk targets (<link linkend='ref-images'>see - the images section</link>) build tarballs that contain toolchains and - libraries suitable for application development outside of Poky. These tarballs - unpack into the + The meta-toolchain and meta-toolchain-sdk targets build tarballs that contain toolchains and + libraries suitable for application development outside of Poky. + For information on these targets see the <ulink linkend='ref-images'>Reference: Images</ulink> + appendix. + </para> + <para> + These tarballs unpack into the <filename class="directory">/opt/poky</filename> directory and contain a setup script (e.g. - <filename>/opt/poky/environment-setup-i586-poky-linux</filename>, which - you can source to initialize a suitable environment. Sourcing these adds the + <filename>/opt/poky/environment-setup-i586-poky-linux</filename>), from which + you can source to initialize a suitable environment. Sourcing these files adds the compiler, QEMU scripts, QEMU binary, a special version of pkgconfig and other useful utilities to the PATH variable. Variables to assist pkgconfig and - autotools are also set so that, for example, configure can find pre-generated test + autotools are also defined so that, for example, configure can find pre-generated test results for tests that need target hardware on which to run. </para> <para> Using the toolchain with autotool-enabled packages is straightforward - just pass the - appropriate host option to configure as in the following example: + appropriate host option to configure. + Following is an example: <literallayout class='monospaced'> $ ./configure --host=arm-poky-linux-gnueabi </literallayout> @@ -47,7 +51,7 @@ easier for the application developer. The plug-ins provide capability extensions to the graphical IDE allowing for cross compilation, deployment and execution of the output in a QEMU emulation session. - Support of these plug-ins also supports cross debugging and + Support of these plug-ins also allows for cross debugging and profiling. Additionally, the Eclipse plug-in provides a suite of tools that allows the developer to perform remote profiling, tracing, collection of power data, collection of latency data and collection of performance data. @@ -57,13 +61,13 @@ <title>The Eclipse Plug-in</title> <para> To use the Eclipse plug-in, a toolchain and SDK built by Poky is required along with - the Eclipse Framework (Helios 3.6). + the Eclipse Framework (Helios 3.6.1). To install the plug-in you need to be in the Eclipse IDE and select the following menu: <literallayout class='monospaced'> Help -> Install New Software </literallayout> - Specify the target URL as http://yocto./download (real link needed). + Specify the target URL as <ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/'></ulink>. </para> <para> If you want to download the source code for the plug-in you can find it in the Poky @@ -74,23 +78,25 @@ <section id="installing-and-setting-up-the-eclipse-ide"> <title>Installing and Setting up the Eclipse IDE</title> <para> - If you don't have the Eclipse IDE (Helios 3.6) on your system you need to + If you don't have the Eclipse IDE (Helios 3.6.1) on your system you need to download and install it from <ulink url="http://www.eclipse.org/downloads"></ulink>. Choose the Eclipse Classic, which contains the Eclipse Platform, Java Development Tools (JDT), and the Plug-in Development Environment. </para> - <para> - NOTE: Due to the Java Virtual Machine's garbage collection (GC) process the - permanent generation space (PermGen) is not cleaned up. This space is used - to store meta-data descriptions of classes. The default value is set too small - and it could trigger an out of memory error like the following: + <note> + <para> + Due to the Java Virtual Machine's garbage collection (GC) process the + permanent generation space (PermGen) is not cleaned up. This space stores + meta-data descriptions of classes. The default value is set too small + and it could trigger an out-of-memory error like the following: <literallayout class='monospaced'> Java.lang.OutOfMemoryError: PermGen space </literallayout> This error causes the applications to hang. - </para> + </para> + </note> <para> - To fix this issue you can use the <command>-vmargs</command> + To fix this issue you can use the <filename>-vmargs</filename> option when you start Eclipse to increase the size of the permenant generation space: <literallayout class='monospaced'> Eclipse -vmargs -XX:PermSize=256M @@ -101,149 +107,173 @@ <section id="installing-the-yocto-plug-in"> <title>Installing the Yocto Plug-in</title> <para> - Once you have the Eclipse IDE installed and configure you need to install the + Once you have the Eclipse IDE installed and configured you need to install the Yocto plug-in. You do this similar to installing the Eclipse plug-ins in the previous section. </para> <para> Do the following to install the Yocto plug-in into the Eclipse IDE: - <itemizedlist> + <orderedlist> <listitem>Select the "Help -> Install New Software" item.</listitem> <listitem>In the "Work with:" area click "Add..." and enter the URL for - the Yocto plug-in (we need to supply this URL).</listitem> + the Yocto plug-in, which is + <ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/'></ulink></listitem> <listitem>Finish out the installation of the update similar to any other Eclipse plug-in.</listitem> - </itemizedlist> + </orderedlist> </para> </section> <section id="configuring-yocto-eclipse-plug-in"> <title>Configuring Yocto Eclipse plug-in</title> <para> - To configure the Yocto Eclipse plug-in you need to select the mode and then the + To configure the Yocto Eclipse plug-in you need to select the mode and the architecture with which you will be working. Start by selecting "Preferences" - from the "Window" menu and then selecting "Yocto SDK". + from the "Window" menu and then select "Yocto SDK". </para> <para> If you normally will use an installed Yocto - SDK (under /opt/poky) select “SDK Root Mode”. Otherwise, if your crosstool chain + SDK (under <filename>/opt/poky</filename>) select “SDK Root Mode”. Otherwise, if your crosstool chain and sysroot are within your poky tree, select “Poky Tree Mode”. - If you are in SDK Root Mode you will need to provide your poky tree path, for - example, $<Poky_tree>/build/. + If you are in SDK Root Mode you need to provide your poky tree path, for + example, <filename>$<Poky_tree>/build/</filename>. </para> <para> - Now you need to select the architecture. + Next, you need to select the architecture. Use the drop down list and select the architecture that you’ll be primarily working against. For target option, select your typical target QEMU vs External HW. If you choose QEMU, you’ll need to specify your QEMU kernel file with full path and the - rootfs mount point. Yocto QEMU boots off user mode NFS, Please refer to QEMU - section for how to set it up. (Section TBD) + rootfs mount point. Yocto QEMU boots off user mode NFS. + See the <link linkend='platdev-appdev-qemu'>Developing Externally in QEMU</link> section for + how to set it up. </para> <para> - Save all your settings and they become your defaults for every new Yocto project - created using the Eclipse IDE. + To make your settings the defaults for every new Yocto project created using + the Eclipse IDE, simply save the settings. </para> </section> <section id="using-the-yocto-eclipse-plug-in"> <title>Using the Yocto Eclipse Plug-in</title> <para> - As an example, this section shows you how to cross-compile a Yocto C autotools - based project, deploy it into QEMU, and then run the debugger against it. - You need to configure the project, trigger <command> autogen.sh</command>, build + As an example, this section shows you how to cross-compile a Yocto C project that + is autotools-based, deploy the project into QEMU, and then run the debugger against it. + You need to configure the project, trigger the <filename> autogen.sh</filename>, build the image, start QEMU, and then debug. </para> + <para> + The following steps show how to create a Yocto autotools-based project using a given template: + </para> <orderedlist> - <listitem>Creating a Yocto Autotools Based Project Using a Template: - Get to the Wizard selection by selecting the File -> New -> Project - menu. Expand "C/C++" and select "C Project". Click "Next" and select a template - to start with, for example "Hello World ANSI C Project". Complete the steps - to create a new Yocto autotools based project using this template.</listitem> - <listitem>Specify Specific Toolchain Configurations: By default the project - uses the Yocto preferences settings as defined using the procedure in - <link linkend="configuring-yocto-eclipse-plug-in"> the previous section</link>. - If there are any specific setup requirements for the newly created project - you need to reconfigure the Yocto plug-in through the menu selection - Project -> Invoke Yocto Tools -> Reconfigure Yocto. Use this dialogue - to specify specific toolchain and QEMU setups for the project.</listitem> - <listitem>Building the Project: Trigger <command>autogen.sh</command> through - Project -> Reconfigure Project. Then build the project using - Project -> Build.</listitem> - <listitem>Starting QEMU: Use the Run -> External Tools menu and see if there is - a QEMU instance for the desired target. If there is click on the instance - to start QEMU. If your target is not there then click "External Tools - Configuration". You should find an instance of QEMU for your architecture - under the entry under "Program". After the boot completes you are ready to - deploy the image into QEMU.</listitem> - <listitem>Debugging: To bring up your remote debugging configuration in the - right-hand window highlight your project in “Project Explorer”, select - the Run -> Debug Configurations menu item and expand “C/C++ Remote Application”. - Next, select projectname_ gdb_target-poky-linux. - You need to be sure that there is an - entry for the remote target you want to deploy and cross debug with. If there - is no entry then click "New..." to bring up the wizard. Using the wizard - select TCF and enter the IP address of you remote target in the - “Host name:” field. Back in the remote debug configure window, - you need to specify the absolute path for the program on the remote target - in the “Remote Absolute File Path for C/C++ Application” field. By default, - the program deploys into the remote target. If you don't want this then check - “Skip download to target path”. Finally, click "Debug” to start the remote - debugging session.</listitem> + <listitem>Select "File -> New -> Project" to start the wizard.</listitem> + <listitem>Expand "C/C++" and select "C Project".</listitem> + <listitem>Click "Next" and select a template (e.g. "Hello World ANSI C Project").</listitem> + <listitem>Complete the steps to create the new Yocto autotools-based project using + your chosen template.</listitem> + </orderedlist> + <para> + By default, the project uses the Yocto preferences settings as defined using the procedure in + <link linkend="configuring-yocto-eclipse-plug-in">the previous section</link>. + If there are any specific setup requirements for the newly created project + you need to reconfigure the Yocto plug-in through the menu selection by doing the following: + </para> + <orderedlist> + <listitem>Select the "Project -> Invoke Yocto Tools -> Reconfigure Yocto" menu item.</listitem> + <listitem>Complete the dialogue to specify the specific toolchain and QEMU setup information.</listitem> + </orderedlist> + <para> + To build the project follow these steps: + </para> + <orderedlist> + <listitem>Select "Project -> Reconfigure Project" to trigger the + <filename>autogen.sh</filename> command.</listitem> + <listitem>Select "Project -> Build" to build the project.</listitem> + </orderedlist> + <para> + To start QEMU follow these steps: + </para> + <orderedlist> + <listitem>Select "Run -> External Tools" and see if there is + a QEMU instance for the desired target. + If one exists, click on the instance to start QEMU. + If your target does not exist, click "External Tools Configuration" and + you should find an instance of QEMU for your architecture + under the entry under "Program".</listitem> + <listitem>Wait for the boot to complete.</listitem> + </orderedlist> + <para> + To deploy your project and start debugging follow these steps: + </para> + <orderedlist> + <listitem>Highlight your project in the project explorer.</listitem> + <listitem>Select "Run -> Debug Configurations" to bring up your remote debugging configuration + in the right-hand window.</listitem> + <listitem>Expand “C/C++ Remote Application”.</listitem> + <listitem>Select "projectname_ gdb_target-poky-linux". + You need to be sure there is an entry for the remote target. + If no entry exists, click "New..." to bring up the wizard. + Use the wizard to select TCF and enter the IP address of you remote target in the + “Host name:” field. + Back in the Remote Debug Configure window, specify in the + “Remote Absolute File Path for C/C++ Application” field the absolute path for the program on + the remote target. + By default, the program deploys into the remote target. + If you don't want this behavior then check “Skip download to target path”.</listitem> + <listitem>Click "Debug” to start the remote debugging session.</listitem> </orderedlist> </section> <section id="using-yocto-eclipse-plug-in-remote-tools-suite"> <title>Using Yocto Eclipse plug-in Remote Tools Suite</title> <para> - Remote tools let you do things like perform system profiling, kernel tracing, + Remote tools allow you to perform system profiling, kernel tracing, examine power consumption, and so forth. To see and access the remote tools use the - Window -> YoctoTools menu. + "Window -> YoctoTools" menu. </para> <para> Once you pick a tool you need to configure it for the remote target. Every tool - needs to have the connection configured. You have to select an existing TCF-based - RSE connection to the remote target. If one does not exist you need to create one - by clicking "New" + needs to have the connection configured. You must select an existing TCF-based + RSE connection to the remote target. If one does not exist, click "New" to create one. </para> <para> Here are some specifics about the remote tools: <itemizedlist> <listitem>Oprofile: Selecting this tool causes the oprofile-server on the remote - target to launch on the local host machine. To use the oprofile the oprofile-viewer + target to launch on the local host machine. The oprofile-viewer must be installed on the local host machine and the oprofile-server must be - installed on the remote target.</listitem> - <listitem>lttng: Selecting this tool runs ustrace on the remote target, transfers - the output data back to the local host machine and uses lttv-gui to graphically - display the output. To use this tool the lttv-gui must be installed on the - local host machine. See <ulink url="http://lttng.org/files/ust/manual/ust.html"> - </ulink> for information on how to use <command>lttng</command> to trace an - application. + installed on the remote target, respectively, in order to use .</listitem> + <listitem>lttng: Selecting this tool runs "ustrace" on the remote target, transfers + the output data back to the local host machine and uses "lttv-gui" to graphically + display the output. The "lttv-gui" must be installed on the + local host machine to use this tool. + For information on how to use "lttng" to trace an + application, see <ulink url="http://lttng.org/files/ust/manual/ust.html"></ulink>. <para> - For "Application" you must supply the absolute path name to the application to - be traced by user mode lttng. For example, typing <command>/path/to/foo" - </command> triggers <command>usttrace /path/to/foo</command> on the - remote target to trace the program <command>/path/to/foo</command>. + For "Application" you must supply the absolute path name of the application to + be traced by user mode lttng. For example, typing <filename>/path/to/foo" + </filename> triggers "usttrace /path/to/foo" on the + remote target to trace the program <filename>/path/to/foo</filename>. </para> <para> "Argument" is passed to "usttrace" running on the remote target. </para> </listitem> - <listitem>powertop: Selecting this tool runs <command>powertop</command> on the - remote target machine and displays the result in a new view called "powertop". + <listitem>powertop: Selecting this tool runs "powertop" on the + remote target machine and displays the results in a new view called "powertop". <para> "Time to gather data(sec):" is the time passed in seconds before data is gathered from the remote target for analysis. </para> <para> - "show pids in wakeups list:" corresponds to the <command>-p</command> - argument passed to <command>powertop</command> + "show pids in wakeups list:" corresponds to the <filename>-p</filename> + argument passed to "powertop". </para> </listitem> - <listitem>latencytop and perf: The <command>latencytop</command> identifies - system latency, while <command>perf</command> monitors the system's performance + <listitem>latencytop and perf: "latencytop" identifies + system latency, while "perf" monitors the system's performance counter registers. Selecting either of these tools causes an RSE - terminal view to appear in which you can run the tools. Both tools refresh the + terminal view to appear from which you can run the tools. Both tools refresh the entire screen to display results while they run.</listitem> </itemizedlist> </para> @@ -252,25 +282,24 @@ <section id="the-anjuta-plug-in"> <title>The Anjuta Plug-in</title> - <para> - <emphasis>Note:</emphasis> We will stop Anjuta plug-in support after - Yocto project 0.9 release. Its source - code can be downloaded from git respository listed below, and free for the community to - continue supporting it moving forward. - </para> + <note> + <para> + Support for the Anjuta plug-in ends after Yocto project 0.9 release. + However, the source code can be downloaded from the git repository listed later in + this section. + The community is free to continue supporting it post 0.9 release. + </para> + </note> <para> An Anjuta IDE plugin exists to make developing software within the Poky framework - easier for the application developer. - It presents a graphical IDE with which you can cross compile an application - then deploy and execute the output in a - QEMU emulation session. - It also supports cross debugging and profiling. + easier for the application developer familiar with that environment. + The plug-in presents a graphical IDE that allows you to cross-compile, cross-debug, + profile, deploy, and execute an application. </para> <para> - To use the plugin, a toolchain and SDK built by Poky is required, - Anjuta, it's development headers and the Anjuta plugin. - The Poky Anjuta plugin is available to download as a tarball at the - OpenedHand + To use the plugin, a toolchain and SDK built by Poky, Anjuta, it's development headers and the Anjuta + Plug-in are all required. + The Poky Anjuta Plug-in is available to download as a tarball at the OpenedHand labs <ulink url="http://labs.o-hand.com/anjuta-poky-sdk-plugin/"></ulink> page or directly from the Poky Git repository located at <ulink url="git://git.pokylinux.org/anjuta-poky"></ulink>. @@ -279,10 +308,9 @@ </para> <para> See the README file contained in the project for more information on - Anjuta dependencies and building the plugin. - If you want to disable remote gdb debugging, - please pass the <command>--diable-gdb-integration</command> switch when doing - configure. + Anjuta dependencies and building the plug-in. + If you want to disable remote gdb debugging, pass the "--diable-gdb-integration" switch when + you configure the plug-in. </para> <section id="setting-up-the-anjuta-plugin"> <title>Setting Up the Anjuta Plug-in</title> @@ -290,18 +318,17 @@ Follow these steps to set up the plug-in: <orderedlist> <listitem>Extract the tarball for the toolchain into / as root. - The toolchain will be installed into <command>/opt/poky</command>.</listitem> + The toolchain will be installed into <filename>/opt/poky</filename>.</listitem> <listitem>To use the plug-in, first open or create an existing project. If you are creating a new project, the "C GTK+" project type will allow itself to be cross-compiled. - However you should be aware that this uses glade for the UI.</listitem> - <listitem>To activate the plug-in go to Edit -> Preferences, then choose - General from the left hand side. - Choose the Installed plug-ins tab, scroll down to Poky SDK and + However, you should be aware that this type uses "glade" for the UI.</listitem> + <listitem>To activate the plug-in, select "Edit -> Preferences" and then choose + "General" from the left hand side. + Choose the "Installed plug-ins" tab, scroll down to "Poky SDK" and check the box.</listitem> </orderedlist> The plug-in is now activated but not configured. - See the next section to learn how to configure it. </para> </section> <section id="configuring-the-anjuta-plugin"> @@ -309,89 +336,82 @@ <para> You can find the configuration options for the SDK by choosing the Poky SDK icon from the left hand side. - You need to set the following options: + You need to define the following options: <itemizedlist> <listitem>SDK root: If you use an external toolchain you need to set - SDK root. This is the root directory of the - SDK's sysroot. - For an i586 SDK this will be <command>/opt/poky/</command>. - This directory will contain <command>bin</command>, <command>include - </command>, <command>var</command> and so forth under your + SDK root, which is the root directory of the SDK's sysroot. + For an i586 SDK directory is <filename>/opt/poky/</filename>. + This directory will contain "bin", "include", "var" and so forth under your selected target architecture subdirectory - <command>/opt/poky/sysroot/i586-poky-linux/</command>. - The cross comple tools you need are in - <command>/opt/poky/sysroot/i586-pokysdk-linux/</command>.</listitem> - <listitem>Poky root: If you have a local poky build tree, you need to - set the Poky root. - This is the root directory of the poky build tree. + <filename>/opt/poky/sysroot/i586-poky-linux/</filename>. + The cross-compile tools you need are in + <filename>/opt/poky/sysroot/i586-pokysdk-linux/</filename>.</listitem> + <listitem>Poky root: If you have a local Poky build tree, you need to + set the Poky root, which is the root directory of the poky build tree. If you build your i586 target architecture under the subdirectory of - <command>build_x86</command> within your poky tree, the Poky root directory - should be <command>$<poky_tree>/build_x86/</command>.</listitem> + <filename>build_x86</filename> within your Poky tree, the Poky root directory + should be <filename>$<poky_tree>/build_x86/</filename>.</listitem> <listitem>Target Architecture: This is the cross compile triplet, for example, "i586-poky-linux". - This target triplet is the prefix extracted from the set up script file - name. - For example, "i586-poky-linux" is extracted from the - set up script file - <command>/opt/poky/environment-setup-i586-poky-linux</command>.</listitem> - <listitem>Kernel: Use the file chooser to select the kernel to use - with QEMU.</listitem> + This target triplet is the prefix extracted from the set up script file's name. + For example, if the script file name is + <filename>/opt/poky/environment-setup-i586-poky-linux</filename> then the extracted target + triplet is "i586-poky-linux".</listitem> + <listitem>Kernel: Use the file chooser to select the kernel used with QEMU.</listitem> <listitem>Root filesystem: Use the file chooser to select the root - filesystem directory. This directory is where you use the - <command>poky-extract-sdk</command> to extract the poky-image-sdk - tarball.</listitem> + filesystem directory. This directory is where you use "poky-extract-sdk" to extract the + poky-image-sdk tarball.</listitem> </itemizedlist> </para> </section> <section id="using-the-anjuta-plug-in"> <title>Using the Anjuta Plug-in</title> <para> - This section uses an example that cross-compiles a project, deploys it into - QEMU, runs a debugger against it and then does a system wide profile. + The steps in this section show how to cross-compile a project, deploy it into + QEMU, run a debugger against it and then perform a system-wide profile. <orderedlist> - <listitem>Choose Build -> Run Configure or Build -> Run Autogenerate to run - "configure" or autogen, respectively for the project. + <listitem>Choose "Build -> Run Configure" or "Build -> Run Autogenerate" to run + "configure" or "autogen", respectively for the project. Either command passes command-line arguments to instruct the cross-compile.</listitem> - <listitem>Select Build -> Build Project to build and compile the project. + <listitem>Choose "Build -> Build Project" to build and compile the project. If you have previously built the project in the same tree without using the cross-compiler you might find that your project fails to link. - If this is the case, simply select Build -> Clean Project to remove the + If this is the case, simply select "Build -> Clean Project" to remove the old binaries. After you clean the project you can then try building it again.</listitem> - <listitem>Start QEMU by selecting Tools -> Start QEMU. This menu selection - starts QEMU and will show any error messages in the message view. - Once Poky has fully booted within QEMU you can now deploy the project + <listitem>Choose "Tools -> Start QEMU" to start QEMU. + After QEMU starts any error messages will appear in the message view. + Once Poky has fully booted within QEMU you can deploy the project into it.</listitem> <listitem>Once the project is built and you have QEMU running choose - Tools -> Deploy. - This selection installs the package into a temporary - directory and then copies using rsync over SSH into the target. - Progress and messages appear in the message view.</listitem> + "Tools -> Deploy" to install the package into a temporary + directory and then copy it using "rsync" over SSH into the target. + A progress bar and appropriate messages appear in the message view.</listitem> <listitem>To debug a program installed onto the target choose - Tools -> Debug remote. - This selection prompts you for the local binary to debug and also the - command line to run on the target. - The command line to run should include the full path to the to binary + "Tools -> Debug remote". + Choosing this menu item causes prompts to appear to define the local binary + for debugging and also for the command line used to run on the target. + When you provide the command line be sure to include the full path to the to binary installed in the target. - This will start a gdbserver over SSH on the target and also an instance - of a cross-gdb in a local terminal. - This will be preloaded to connect to the server and use the SDK root to + When the command line runs a "gdbserver" over SSH is started on the target and + an instance of "cross-gdb" starts in a local terminal. + The instance of "cross-gdb" will be preloaded to connect to the server and use the SDK root to find symbols. - This gdb will connect to the target and load in various libraries and the + It also connects to the target and loads in various libraries as well as the target program. - You should setup any breakpoints or watchpoints now since you might not + You should define any breakpoints or watchpoints at this point in the process since you might not be able to interrupt the execution later. - You can stop the debugger on the target using Tools -> Stop debugger.</listitem> - <listitem>It is also possible to execute a command in the target over SSH, - the appropriate environment will be be set for the execution. - Choose Tools -> Run remote to do this. + To stop the debugger on the target choose "Tools -> Stop debugger".</listitem> + <listitem>It is also possible to execute a command in the target over SSH. + Doing so causes the appropriate environment to be established for execution. + To execute a command choose "Choose Tools -> Run remote". This selection opens a terminal with the SSH command inside.</listitem> - <listitem>To do a system wide profile against the system running in QEMU choose - Tools -> Profile remote. - This selection starts up OProfileUI with the appropriate parameters to + <listitem>To perform a system-wide profile against the system running in QEMU choose + "Tools -> Profile remote". + This choice starts up "OProfileUI" with the appropriate parameters to connect to the server running inside QEMU and also supplies the path - to the debug information necessary to get a useful profile.</listitem> + for debug information necessary to get a useful profile.</listitem> </orderedlist> </para> </section> @@ -399,7 +419,7 @@ </section> <section id="platdev-appdev-qemu"> - <title>Developing externally in QEMU</title> + <title>Developing Externally in QEMU</title> <para> Running Poky QEMU images is covered in the <ulink url="http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html"> @@ -407,35 +427,36 @@ </para> <para> Poky's QEMU images contain a complete native toolchain. This means - that applications can be developed within QEMU in the same was as a - normal system. Using qemux86 on an x86 machine is fast since the - guest and host architectures match, qemuarm is slower but gives - faithful emulation of ARM specific issues. To speed things up these - images support using distcc to call a cross-compiler outside the - emulated system too. If <command>runqemu</command> was used to start - QEMU, and distccd is present on the host system, any bitbake cross - compiling toolchain available from the build system will automatically - be used from within qemu simply by calling distcc - (<command>export CC="distcc"</command> can be set in the enviroment). + you can develop applications within QEMU similar to the way you would in a normal system. + Using qemux86 on an x86 machine is fast since the + guest and host architectures match. + On the other hand, using qemuarm can be slower but gives + faithful emulation of ARM-specific issues. To speed things up, these + images support using "distcc" to call a cross-compiler outside the + emulated system. If "runqemu" was used to start + QEMU, and "distccd" is present on the host system, any Bitbake cross-compiling + toolchain available from the build system is automatically + used from within QEMU simply by calling "distcc". You can accomplish this by defining the + cross-compiler variable (e.g. <filename>export CC="distcc"</filename>). Alterntatively, if a suitable SDK/toolchain is present in - <filename class="directory">/opt/poky</filename> it will also + <filename>/opt/poky</filename> it is also automatically be used. </para> <para> There are several options for connecting into the emulated system. - QEMU provides a framebuffer interface which has standard consoles - available. There is also a serial connection available which has a - console to the system running on it and IP networking as standard. + QEMU provides a framebuffer interface that has standard consoles + available. There is also a serial connection available that has a + console to the system running on it and uses standard IP networking. The images have a dropbear ssh server running with the root password - disabled allowing standard ssh and scp commands to work. The images - also contain an NFS server exporting the guest's root filesystem - allowing that to be made available to the host. + disabled to allow standard ssh and scp commands to work. The images + also contain an NFS server that exports the guest's root filesystem, which + allows it to be made available to the host. </para> </section> <section id="platdev-appdev-insitu"> - <title>Developing in Poky directly</title> + <title>Developing in Poky Directly</title> <para> Working directly in Poky is a fast and effective development technique. The idea is that you can directly edit files in @@ -448,36 +469,36 @@ <para> <literallayout class='monospaced'> -$ bitbake matchbox-desktop -$ sh -$ cd tmp/work/armv5te-poky-linux-gnueabi/matchbox-desktop-2.0+svnr1708-r0/ -$ cd matchbox-desktop-2 -$ vi src/main.c -$ exit -$ bitbake matchbox-desktop -c compile -f -$ bitbake matchbox-desktop -</literallayout> + $ bitbake matchbox-desktop + $ sh + $ cd tmp/work/armv5te-poky-linux-gnueabi/matchbox-desktop-2.0+svnr1708-r0/ + $ cd matchbox-desktop-2 + $ vi src/main.c + $ exit + $ bitbake matchbox-desktop -c compile -f + $ bitbake matchbox-desktop + </literallayout> </para> <para> - Here, we build the package, change into the work directory for the package, - change a file, then recompile the package. Instead of using sh like this, - you can also use two different terminals. The risk with working like this - is that a command like unpack could wipe out the changes you've made to the - work directory so you need to work carefully. + This example builds the package, changes into the work directory for the package, + changes a file, then recompiles the package. Instead of using "sh" as it is in the example, + you can also use two different terminals. However, the risk of using two terminals + is that a command like "unpack" could destroy the changes you've made to the + work directory. Consequently, you need to work carefully. </para> <para> It is useful when making changes directly to the work directory files to do - so using quilt as detailed in the <link linkend='usingpoky-modifying-packages-quilt'> - modifying packages with quilt</link> section. The resulting patches can be copied - into the recipe directory and used directly in the <glossterm><link + so using "quilt" as detailed in the <link linkend='usingpoky-modifying-packages-quilt'> + modifying packages with quilt</link> section. You can copy the resulting patches + into the recipe directory and use them directly in the <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm>. </para> <para> - For a review of the skills used in this section see Sections <link - linkend="usingpoky-components-bitbake">2.1.1</link> and <link - linkend="usingpoky-debugging-taskrunning">2.4.2</link>. + For a review of the skills used in this section see the <link + linkend="usingpoky-components-bitbake">Bitbake</link> and <link + linkend="usingpoky-debugging-taskrunning">Running Specific Tasks</link> Sections. </para> </section> @@ -485,67 +506,75 @@ $ bitbake matchbox-desktop <title>Developing with 'devshell'</title> <para> - When debugging certain commands or even to just edit packages, the - 'devshell' can be a useful tool. To start it you run a command like: + When debugging certain commands or even when just editing packages, the + 'devshell' can be a useful tool. + Use a command like the following to start this tool. </para> <para> <literallayout class='monospaced'> -$ bitbake matchbox-desktop -c devshell -</literallayout> + $ bitbake matchbox-desktop -c devshell + </literallayout> </para> <para> - which will open a terminal with a shell prompt within the Poky - environment. This means PATH is setup to include the cross toolchain, - the pkgconfig variables are setup to find the right .pc files, - configure will be able to find the Poky site files etc. Within this - environment, you can run configure or compile command as if they - were being run by Poky itself. You are also changed into the - source (<glossterm><link linkend='var-S'>S</link></glossterm>) - directory automatically. When finished with the shell just exit it - or close the terminal window. + This command opens a terminal with a shell prompt within the Poky + environment. Consequently, the following occurs: + <itemizedlist> + <listitem>The PATH variable includes the cross toolchain.</listitem> + <listitem>The pkgconfig variables find the correct <filename>.pc</filename> files.</listitem> + <listitem>"configure" finds the Poky site files as well as any other necessary files.</listitem> + </itemizedlist> + Within this environment, you can run "configure" or "compile" commands as if they + were being run by Poky itself. + The working directory also automatically changes to the (<glossterm><link linkend='var-S'>S</link></glossterm>) + directory. + When you are finished, you just exit the shell or close the terminal window. </para> <para> - The default shell used by devshell is the gnome-terminal. Other - forms of terminal can also be used by setting the <glossterm> + The default shell used by "devshell" is the gnome-terminal. + You can use other forms of terminal can by setting the <glossterm> <link linkend='var-TERMCMD'>TERMCMD</link></glossterm> and <glossterm> <link linkend='var-TERMCMDRUN'>TERMCMDRUN</link></glossterm> variables - in local.conf. For examples of the other options available, see - <filename>meta/conf/bitbake.conf</filename>. An external shell is - launched rather than opening directly into the original terminal - window to make interaction with bitbakes multiple threads easier - and also allow a client/server split of bitbake in the future - (devshell will still work over X11 forwarding or similar). + in <filename>local.conf</filename>. + For examples of the other options available, see + <filename>meta/conf/bitbake.conf</filename>. + </para> + <para> + An external shell is launched rather than opening directly into the original terminal + window. + This allows easier interaction with Bitbake's multiple threads as well as + for a future client/server split. + Note that "devshell" will still work over X11 forwarding or similar situations. </para> <para> - It is worth remembering that inside devshell you need to use the full - compiler name such as <command>arm-poky-linux-gnueabi-gcc</command> - instead of just <command>gcc</command> and the same applies to other - applications from gcc, bintuils, libtool etc. Poky will have setup - environmental variables such as CC to assist applications, such as make, + It is worth remembering that inside "devshell" you need to use the full + compiler name such as <filename>arm-poky-linux-gnueabi-gcc</filename> + instead of just <filename>gcc</filename>. + The same applies to other applications such as gcc, bintuils, libtool and so forth. + Poky will have setup environmental variables such as CC to assist applications, such as make, find the correct tools. </para> </section> <section id="platdev-appdev-srcrev"> - <title>Developing within Poky with an external SCM based package</title> + <title>Developing within Poky with an External SCM-based Package</title> <para> - If you're working on a recipe which pulls from an external SCM it + If you're working on a recipe that pulls from an external SCM it is possible to have Poky notice new changes added to the - SCM and then build the latest version. This only works for SCMs - where its possible to get a sensible revision number for changes. + SCM and then build the latest version using them. + This only works for SCMs from which it is possible to get a sensible revision number for changes. Currently it works for svn, git and bzr repositories. </para> <para> - To enable this behaviour it is simply a case of adding <glossterm> + To enable this behavior simply add <glossterm> <link linkend='var-SRCREV'>SRCREV</link></glossterm>_pn-<glossterm> <link linkend='var-PN'>PN</link></glossterm> = "${AUTOREV}" to - local.conf where <glossterm><link linkend='var-PN'>PN</link></glossterm> + <filename>local.conf</filename>, where <glossterm><link linkend='var-PN'>PN</link></glossterm> is the name of the package for which you want to enable automatic source revision updating. </para> |