%poky; ] > Platform Development with the Yocto Project
Application Development Using the Yocto Project The Yocto Project supports several methods of application development through which you can create user-space software designed to run on an embedded device that uses a Yocto Project image, which was developed with the OpenEmbedded build system. This flexibility allows you to choose the method that works best for you. This chapter describes each development method.
Development Within a Development Shell When debugging certain commands or even when just editing packages, devshell can be a useful tool. Using devshell differs from the example shown in the previous section in that when you invoke devshell source files are extracted into your working directory and patches are applied. Then, a new terminal is opened and you are placed in the working directory. In the new terminal, all the OpenEmbedded build-related environment variables are still defined so you can use commands such as configure and make. The commands execute just as if the OpenEmbedded build system were executing them. Consequently, working this way can be helpful when debugging a build or preparing software to be used with the OpenEmbedded build system. Following is an example that uses devshell on a target named matchbox-desktop: $ bitbake matchbox-desktop -c devshell This command opens a terminal with a shell prompt within the Yocto Project environment. The following occurs: The PATH variable includes the cross-toolchain. The pkgconfig variables find the correct .pc files. The configure command finds the Yocto Project site files as well as any other necessary files. Within this environment, you can run configure or compile commands as if they were being run by the OpenEmbedded build system itself. As noted earlier, the working directory also automatically changes to the source directory (S). When you are finished, you just exit the shell or close the terminal window. The default shell used by devshell is xterm. For examples of available options, see the "UI/Interaction Configuration" section of the meta/conf/bitbake.conf configuration file in the source directory. Because an external shell is launched rather than opening directly into the original terminal window, it allows easier interaction with BitBake's multiple threads as well as accomodates a future client/server split. It is worth remembering that when using devshell you need to use the full compiler name such as arm-poky-linux-gnueabi-gcc instead of just using gcc. The same applies to other applications such as binutils, libtool and so forth. BitBake sets up environment variables such as CC to assist applications, such as make to find the correct tools. It is also worth noting that devshell still works over X11 forwarding and similar situations
Development Within Yocto Project for a Package that Uses an External SCM If you're working on a recipe that pulls from an external Source Code Manager (SCM), it is possible to have the OpenEmbedded build system notice new changes added to the SCM and then build the package that depends on them using the latest version. This only works for SCMs from which it is possible to get a sensible revision number for changes. Currently, you can do this with Apache Subversion (SVN), Git, and Bazaar (BZR) repositories. To enable this behavior, simply add the following to the local.conf configuration file found in the build directory: SRCREV_pn-<PN> = "${AUTOREV}" where PN is the name of the package for which you want to enable automatic source revision updating.