diff --git a/documentation/sdk-manual/sdk-extensible.xml b/documentation/sdk-manual/sdk-extensible.xml index 73b317f5c8..8c568a739e 100644 --- a/documentation/sdk-manual/sdk-extensible.xml +++ b/documentation/sdk-manual/sdk-extensible.xml @@ -4,79 +4,150 @@ -Using the Extensible SDK - - - This chapter describes the extensible SDK and how to use it. - The extensible SDK makes it easy to add new applications and libraries - to an image, modify the source for an existing component, test - changes on the target hardware, and ease integration into the rest of the - OpenEmbedded build system. - - - - Information in this chapter covers features that are not part of the - standard SDK. - In other words, the chapter presents information unique to the - extensible SDK only. - For information on how to use the standard SDK, see the - "Using the Standard SDK" - chapter. - - -
- Setting Up to Use the Extensible SDK + Using the Extensible SDK - Getting set up to use the extensible SDK is identical to getting set - up to use the standard SDK. - You still need to locate and run the installer and then run the - environment setup script. + This chapter describes the extensible SDK and how to install it. + Information covers the pieces of the SDK, how to install it, and + presents a look at using the devtool + functionality. + The extensible SDK makes it easy to add new applications and libraries + to an image, modify the source for an existing component, test + changes on the target hardware, and ease integration into the rest of + the + OpenEmbedded build system. + + For a side-by-side comparison of main features supported for an + extensible SDK as compared to a standard SDK, see the + "Introduction" + section. + + + + + You can use an extensible SDK to work on Makefile, Autotools, and + Eclipse-based projects. See the - "Installing the SDK" - and the - "Running the SDK Environment Setup Script" - sections for general information. - The following items highlight the only differences between getting - set up to use the extensible SDK as compared to the standard SDK: - - Default Installation Directory: - By default, the extensible SDK installs into the - poky_sdk folder of your home directory. - As with the standard SDK, you can choose to install the - extensible SDK in any location when you run the installer. - However, unlike the standard SDK, the location you choose needs - to be writable for whichever users need to use the SDK, - since files will need to be written under that directory during - the normal course of operation. - - Build Tools and Build System: - The extensible SDK installer performs additional tasks as - compared to the standard SDK installer. - to the SDK and the installer also prepares the internal build - system within the SDK. - You can find pre-built extensible SDK installers in the same - toolchain - location as the pre-built standard SDK installers. - For extensible SDK installers, the - ext string is part of the name. - Here is an example: - - poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh - - - As an alternative to downloading an SDK, you can build the toolchain - installer. - For information on building the installer, see the - "Building an SDK Installer" - section. - Another helpful resource for building an installer is the - Cookbook guide to Making an Eclipse Debug Capable Image - wiki page. - - Here is example output for running the extensible SDK - installer: - + "Working with Different Types of Projects" + chapter for more information. + + +
+ Why use the Extensible SDK and What is in It? + + + The extensible SDK provides a cross-development toolchain and + libraries tailored to the contents of a specific image. + You would use the Extensible SDK if you want a toolchain experience + supplemented with the powerful set of devtool + commands tailored for the Yocto Project environment. + + + + The installed extensible SDK consists of several files and + directories. + Basically, it contains an SDK environment setup script, some + configuration files, an internal build system, and the + devtool functionality. + +
+ +
+ Setting Up to Use the Extensible SDK + + + The first thing you need to do is install the SDK on your host + development machine by running the *.sh + installation script. + + + + You can download a tarball installer, which includes the + pre-built toolchain, the runqemu + script, the internal build system, devtool, + and support files from the appropriate directory under + . + Toolchains are available for 32-bit and 64-bit x86 development + systems from the i686 and + x86_64 directories, respectively. + The toolchains the Yocto Project provides are based off the + core-image-sato image and contain + libraries appropriate for developing against that image. + Each type of development system supports five or more target + architectures. + + + + The names of the tarball installer scripts are such that a + string representing the host system appears first in the + filename and then is immediately followed by a string + representing the target architecture. + An extensible SDK has the string "-ext" as part of the name. + + poky-glibc-host_system-image_type-arch-toolchain-ext-release_version.sh + + Where: + host_system is a string representing your development system: + + i686 or x86_64. + + image_type is the image for which the SDK was built. + + arch is a string representing the tuned target architecture: + + i586, x86_64, powerpc, mips, armv7a or armv5te + + release_version is a string representing the release number of the + Yocto Project: + + &DISTRO;, &DISTRO;+snapshot + + For example, the following toolchain installer is for a 64-bit + development host system and a i586-tuned target architecture + based off the SDK for core-image-sato and + using the current &DISTRO; snapshot: + + poky-glibc-x86_64-core-image-sato-i586-toolchain-ext-&DISTRO;.sh + + + As an alternative to downloading an SDK, you can build the + toolchain installer. + For information on building the installer, see the + "Building an SDK Installer" + section. + Another helpful resource for building an installer is the + Cookbook guide to Making an Eclipse Debug Capable Image + wiki page. + This wiki page focuses on development when using the Eclipse + IDE. + + + + + The SDK and toolchains are self-contained and by default are + installed into the poky_sdk folder in your + home directory. + You can choose to install the extensible SDK in any location when + you run the installer. + However, the location you choose needs to be writable for whichever + users need to use the SDK, since files will need to be written + under that directory during the normal course of operation. + + + + The following command shows how to run the installer given a + toolchain tarball for a 64-bit x86 development host system and + a 64-bit x86 target architecture. + The example assumes the toolchain installer is located in + ~/Downloads/. + + If you do not have write permissions for the directory + into which you are installing the SDK, the installer + notifies you and exits. + Be sure you have write permissions in the directory and + run the installer again. + + $ ./poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-&DISTRO;.sh Poky (Yocto Project Reference Distro) Extensible SDK installer version &DISTRO; =================================================================================== @@ -90,1430 +161,1471 @@ SDK has been successfully set up and is ready to be used. Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g. $ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux - - - - + + +
- - After installing the SDK, you need to run the SDK environment setup - script. - Here is the output from an example run: - +
+ Running the Extensible SDK Environment Setup Script + + + Once you have the SDK installed, you must run the SDK environment + setup script before you can actually use it. + This setup script resides in the directory you chose when you + installed the SDK, which is either the default + poky_sdk directory or the directory you + chose during installation. + + + + Before running the script, be sure it is the one that matches the + architecture for which you are developing. + Environment setup scripts begin with the string + "environment-setup" and include as part of + their name the tuned target architecture. + As an example, the following commands set the working directory + to where the SDK was installed and then source the environment + setup script. + In this example, the setup script is for an IA-based + target machine using i586 tuning: + $ cd /home/scottrif/poky_sdk $ source environment-setup-core2-64-poky-linux SDK environment now set up; additionally you may now run devtool to perform development tasks. Run devtool --help for further details. - - Once you run the environment setup script, you have - devtool available. - -
+ + When you run the setup script, many environment variables are + defined: + + SDKTARGETSYSROOT - The path to the sysroot used for cross-compilation + PKG_CONFIG_PATH - The path to the target pkg-config files + CONFIG_SITE - A GNU autoconf site file preconfigured for the target + CC - The minimal command and arguments to run the C compiler + CXX - The minimal command and arguments to run the C++ compiler + CPP - The minimal command and arguments to run the C preprocessor + AS - The minimal command and arguments to run the assembler + LD - The minimal command and arguments to run the linker + GDB - The minimal command and arguments to run the GNU Debugger + STRIP - The minimal command and arguments to run 'strip', which strips symbols + RANLIB - The minimal command and arguments to run 'ranlib' + OBJCOPY - The minimal command and arguments to run 'objcopy' + OBJDUMP - The minimal command and arguments to run 'objdump' + AR - The minimal command and arguments to run 'ar' + NM - The minimal command and arguments to run 'nm' + TARGET_PREFIX - The toolchain binary prefix for the target tools + CROSS_COMPILE - The toolchain binary prefix for the target tools + CONFIGURE_FLAGS - The minimal arguments for GNU configure + CFLAGS - Suggested C flags + CXXFLAGS - Suggested C++ flags + LDFLAGS - Suggested linker flags when you use CC to link + CPPFLAGS - Suggested preprocessor flags + + +
-
- Using <filename>devtool</filename> in Your SDK Workflow - - - The cornerstone of the extensible SDK is a command-line tool - called devtool. - This tool provides a number of features that help - you build, test and package software within the extensible SDK, and - optionally integrate it into an image built by the OpenEmbedded build - system. - - - - The devtool command line is organized similarly - to - Git in that it has a - number of sub-commands for each function. - You can run devtool --help to see all the - commands. - - See the - "devtool Quick Reference" - in the Yocto Project Reference Manual for more a - devtool reference. - - - - - Two devtool subcommands that provide - entry-points into development are: - - devtool add: - Assists in adding new software to be built. - - devtool modify: - Sets up an environment to enable you to modify the source of - an existing component. - - - As with the OpenEmbedded build system, "recipes" represent software - packages within devtool. - When you use devtool add, a recipe is - automatically created. - When you use devtool modify, the specified - existing recipe is used in order to determine where to get the source - code and how to patch it. - In both cases, an environment is set up so that when you build the - recipe a source tree that is under your control is used in order to - allow you to make changes to the source as desired. - By default, both new recipes and the source go into a "workspace" - directory under the SDK. - - - - The remainder of this section presents the - devtool add and - devtool modify workflows. - - -
- Use <filename>devtool add</filename> to Add an Application +
+ Using <filename>devtool</filename> in Your SDK Workflow - The devtool add command generates - a new recipe based on existing source code. - This command takes advantage of the - workspace - layer that many devtool commands - use. - The command is flexible enough to allow you to extract source - code into both the workspace or a separate local Git repository - and to use existing code that does not need to be extracted. + The cornerstone of the extensible SDK is a command-line tool + called devtool. + This tool provides a number of features that help + you build, test and package software within the extensible SDK, and + optionally integrate it into an image built by the OpenEmbedded build + system. - Depending on your particular scenario, the arguments and options - you use with devtool add form different - combinations. - The following diagram shows common development flows - you would use with the devtool add - command: + The devtool command line is organized similarly + to + Git in that it has a + number of sub-commands for each function. + You can run devtool --help to see all the + commands. + + See the + "devtool Quick Reference" + in the Yocto Project Reference Manual for more a + devtool reference. + - + Two devtool subcommands that provide + entry-points into development are: + + devtool add: + Assists in adding new software to be built. + + devtool modify: + Sets up an environment to enable you to modify the source of + an existing component. + + + As with the OpenEmbedded build system, "recipes" represent software + packages within devtool. + When you use devtool add, a recipe is + automatically created. + When you use devtool modify, the specified + existing recipe is used in order to determine where to get the source + code and how to patch it. + In both cases, an environment is set up so that when you build the + recipe a source tree that is under your control is used in order to + allow you to make changes to the source as desired. + By default, both new recipes and the source go into a "workspace" + directory under the SDK. - - Generating the New Recipe: - The top part of the flow shows three scenarios by which - you could use devtool add to - generate a recipe based on existing source code. + The remainder of this section presents the + devtool add and + devtool modify workflows. + - In a shared development environment, it is - typical where other developers are responsible for - various areas of source code. - As a developer, you are probably interested in using - that source code as part of your development using - the Yocto Project. - All you need is access to the code, a recipe, and a - controlled area in which to do your work. +
+ Use <filename>devtool add</filename> to Add an Application - Within the diagram, three possible scenarios - feed into the devtool add workflow: - - Left: - The left scenario represents a common situation - where the source code does not exist locally - and needs to be extracted. - In this situation, you just let it get - extracted to the default workspace - you do not - want it in some specific location outside of the - workspace. - Thus, everything you need will be located in the - workspace: - + + The devtool add command generates + a new recipe based on existing source code. + This command takes advantage of the + workspace + layer that many devtool commands + use. + The command is flexible enough to allow you to extract source + code into both the workspace or a separate local Git repository + and to use existing code that does not need to be extracted. + + + + Depending on your particular scenario, the arguments and options + you use with devtool add form different + combinations. + The following diagram shows common development flows + you would use with the devtool add + command: + + + + + + + + + Generating the New Recipe: + The top part of the flow shows three scenarios by which + you could use devtool add to + generate a recipe based on existing source code. + + In a shared development environment, it is + typical where other developers are responsible for + various areas of source code. + As a developer, you are probably interested in using + that source code as part of your development using + the Yocto Project. + All you need is access to the code, a recipe, and a + controlled area in which to do your work. + + Within the diagram, three possible scenarios + feed into the devtool add workflow: + + Left: + The left scenario represents a common situation + where the source code does not exist locally + and needs to be extracted. + In this situation, you just let it get + extracted to the default workspace - you do not + want it in some specific location outside of the + workspace. + Thus, everything you need will be located in the + workspace: + $ devtool add recipe fetchuri - - With this command, devtool - creates a recipe and an append file in the - workspace as well as extracts the upstream - source files into a local Git repository also - within the sources folder. - - Middle: - The middle scenario also represents a situation where - the source code does not exist locally. - In this case, the code is again upstream - and needs to be extracted to some - local area - this time outside of the default - workspace. - If required, devtool - always creates - a Git repository locally during the extraction. - Furthermore, the first positional argument - srctree in this case - identifies where the - devtool add command - will locate the extracted code outside of the - workspace: - + + With this command, devtool + creates a recipe and an append file in the + workspace as well as extracts the upstream + source files into a local Git repository also + within the sources folder. + + Middle: + The middle scenario also represents a situation where + the source code does not exist locally. + In this case, the code is again upstream + and needs to be extracted to some + local area - this time outside of the default + workspace. + If required, devtool + always creates + a Git repository locally during the extraction. + Furthermore, the first positional argument + srctree in this case + identifies where the + devtool add command + will locate the extracted code outside of the + workspace: + $ devtool add recipe srctree fetchuri - - In summary, the source code is pulled from - fetchuri and extracted - into the location defined by - srctree as a local - Git repository. + + In summary, the source code is pulled from + fetchuri and extracted + into the location defined by + srctree as a local + Git repository. - Within workspace, devtool - creates both the recipe and an append file - for the recipe. - - Right: - The right scenario represents a situation - where the source tree (srctree) has been - previously prepared outside of the - devtool workspace. - + Within workspace, devtool + creates both the recipe and an append file + for the recipe. + + Right: + The right scenario represents a situation + where the source tree (srctree) has been + previously prepared outside of the + devtool workspace. + - The following command names the recipe - and identifies where the existing source tree - is located: - + The following command names the recipe + and identifies where the existing source tree + is located: + $ devtool add recipe srctree - - The command examines the source code and creates - a recipe for it placing the recipe into the - workspace. + + The command examines the source code and creates + a recipe for it placing the recipe into the + workspace. - Because the extracted source code already exists, - devtool does not try to - relocate it into the workspace - just the new - the recipe is placed in the workspace. + Because the extracted source code already exists, + devtool does not try to + relocate it into the workspace - just the new + the recipe is placed in the workspace. - Aside from a recipe folder, the command - also creates an append folder and places an initial - *.bbappend within. - - - - Edit the Recipe: - At this point, you can use devtool edit-recipe - to open up the editor as defined by the - $EDITOR environment variable - and modify the file: - - $ devtool edit-recipe recipe - - From within the editor, you can make modifications to the - recipe that take affect when you build it later. - - Build the Recipe or Rebuild the Image: - At this point in the flow, the next step you - take depends on what you are going to do with - the new code. - If you need to take the build output and eventually - move it to the target hardware, you would use - devtool build: - - $ devtool build recipe - - On the other hand, if you want an image to - contain the recipe's packages for immediate deployment - onto a device (e.g. for testing purposes), you can use - the devtool build-image command: - - $ devtool build-image image - - - Deploy the Build Output: - When you use the devtool build - command to build out your recipe, you probably want to - see if the resulting build output works as expected on target - hardware. - - This step assumes you have a previously built - image that is already either running in QEMU or - running on actual hardware. - Also, it is assumed that for deployment of the image - to the target, SSH is installed in the image and if - the image is running on real hardware that you have - network access to and from your development machine. - - You can deploy your build output to that target hardware by - using the devtool deploy-target command: - - $ devtool deploy-target recipe target - - The target is a live target machine - running as an SSH server. - - You can, of course, also deploy the image you build - using the devtool build-image command - to actual hardware. - However, devtool does not provide a - specific command that allows you to do this. - - - Finish Your Work With the Recipe: - The devtool finish command creates - any patches corresponding to commits in the local - Git repository, moves the new recipe to a more permanent - layer, and then resets the recipe so that the recipe is - built normally rather than from the workspace. - - $ devtool finish recipe layer - - - Any changes you want to turn into patches must be - committed to the Git repository in the source tree. - - - As mentioned, the devtool finish - command moves the final recipe to its permanent layer. - - - As a final process of the - devtool finish command, the state - of the standard layers and the upstream source is - restored so that you can build the recipe from those - areas rather than the workspace. - - You can use the devtool reset - command to put things back should you decide you - do not want to proceed with your work. - If you do use this command, realize that the source - tree is preserved. - - - - -
- -
- Use <filename>devtool modify</filename> to Modify the Source of an Existing Component - - - The devtool modify command prepares the - way to work on existing code that already has a recipe in - place. - The command is flexible enough to allow you to extract code, - specify the existing recipe, and keep track of and gather any - patch files from other developers that are - associated with the code. - - - - Depending on your particular scenario, the arguments and options - you use with devtool modify form different - combinations. - The following diagram shows common development flows - you would use with the devtool modify - command: - - - - - - - - - Preparing to Modify the Code: - The top part of the flow shows three scenarios by which - you could use devtool modify to - prepare to work on source files. - Each scenario assumes the following: - - The recipe exists in some layer external - to the devtool workspace. - - The source files exist upstream in an - un-extracted state or locally in a previously - extracted state. - - - The typical situation is where another developer has - created some layer for use with the Yocto Project and - their recipe already resides in that layer. - Furthermore, their source code is readily available - either upstream or locally. - - Left: - The left scenario represents a common situation - where the source code does not exist locally - and needs to be extracted. - In this situation, the source is extracted - into the default workspace location. - The recipe, in this scenario, is in its own - layer outside the workspace - (i.e. - meta-layername). - - - The following command identifies the recipe - and by default extracts the source files: - - $ devtool modify recipe - - Once devtoollocates the recipe, - it uses the - SRC_URI - variable to locate the source code and - any local patch files from other developers are - located. - - You cannot provide an URL for - srctree when using the - devtool modify command. - - With this scenario, however, since no - srctree argument exists, the - devtool modify command by default - extracts the source files to a Git structure. - Furthermore, the location for the extracted source is the - default area within the workspace. - The result is that the command sets up both the source - code and an append file within the workspace with the - recipe remaining in its original location. - - Middle: - The middle scenario represents a situation where - the source code also does not exist locally. - In this case, the code is again upstream - and needs to be extracted to some - local area as a Git repository. - The recipe, in this scenario, is again in its own - layer outside the workspace. - - The following command tells - devtool what recipe with - which to work and, in this case, identifies a local - area for the extracted source files that is outside - of the default workspace: - - $ devtool modify recipe srctree - - As with all extractions, the command uses - the recipe's SRC_URI to locate the - source files. - Once the files are located, the command by default - extracts them. - Providing the srctree - argument instructs devtool where - place the extracted source. - - Within workspace, devtool - creates an append file for the recipe. - The recipe remains in its original location but - the source files are extracted to the location you - provided with srctree. - - Right: - The right scenario represents a situation - where the source tree - (srctree) exists as a - previously extracted Git structure outside of - the devtool workspace. - In this example, the recipe also exists - elsewhere in its own layer. - - - The following command tells - devtool the recipe - with which to work, uses the "-n" option to indicate - source does not need to be extracted, and uses - srctree to point to the - previously extracted source files: - - $ devtool modify -n recipe srctree - - - - Once the command finishes, it creates only - an append file for the recipe in the workspace. - The recipe and the source code remain in their - original locations. - + Aside from a recipe folder, the command + also creates an append folder and places an initial + *.bbappend within. + - - Edit the Source: - Once you have used the devtool modify - command, you are free to make changes to the source - files. - You can use any editor you like to make and save - your source code modifications. - - Build the Recipe: - Once you have updated the source files, you can build - the recipe. - - Deploy the Build Output: - When you use the devtool build - command to build out your recipe, you probably want to see - if the resulting build output works as expected on target - hardware. - - This step assumes you have a previously built - image that is already either running in QEMU or - running on actual hardware. - Also, it is assumed that for deployment of the image - to the target, SSH is installed in the image and if - the image is running on real hardware that you have - network access to and from your development machine. - - You can deploy your build output to that target hardware by - using the devtool deploy-target command: - + + Edit the Recipe: + At this point, you can use devtool edit-recipe + to open up the editor as defined by the + $EDITOR environment variable + and modify the file: + + $ devtool edit-recipe recipe + + From within the editor, you can make modifications to the + recipe that take affect when you build it later. + + Build the Recipe or Rebuild the Image: + At this point in the flow, the next step you + take depends on what you are going to do with + the new code. + If you need to take the build output and eventually + move it to the target hardware, you would use + devtool build: + + $ devtool build recipe + + On the other hand, if you want an image to + contain the recipe's packages for immediate deployment + onto a device (e.g. for testing purposes), you can use + the devtool build-image command: + + $ devtool build-image image + + + Deploy the Build Output: + When you use the devtool build + command to build out your recipe, you probably want to + see if the resulting build output works as expected on target + hardware. + + This step assumes you have a previously built + image that is already either running in QEMU or + running on actual hardware. + Also, it is assumed that for deployment of the image + to the target, SSH is installed in the image and if + the image is running on real hardware that you have + network access to and from your development machine. + + You can deploy your build output to that target hardware by + using the devtool deploy-target command: + $ devtool deploy-target recipe target - - The target is a live target machine - running as an SSH server. + + The target is a live target machine + running as an SSH server. - You can, of course, also deploy the image you build - using the devtool build-image command - to actual hardware. - However, devtool does not provide a - specific command that allows you to do this. - - - Finish Your Work With the Recipe: - The devtool finish command creates - any patches corresponding to commits in the local - Git repository, updates the recipe to point to them - (or creates a .bbappend file to do - so, depending on the specified destination layer), and - then resets the recipe so that the recipe is built normally - rather than from the workspace. - + You can, of course, also deploy the image you build + using the devtool build-image command + to actual hardware. + However, devtool does not provide a + specific command that allows you to do this. + + + Finish Your Work With the Recipe: + The devtool finish command creates + any patches corresponding to commits in the local + Git repository, moves the new recipe to a more permanent + layer, and then resets the recipe so that the recipe is + built normally rather than from the workspace. + $ devtool finish recipe layer - - - Any changes you want to turn into patches must be - committed to the Git repository in the source tree. - + + + Any changes you want to turn into patches must be + committed to the Git repository in the source tree. + - Because there is no need to move the recipe, - devtool finish either updates the - original recipe in the original layer or the command - creates a .bbappend in a different - layer as provided by layer. - + As mentioned, the devtool finish + command moves the final recipe to its permanent layer. + - As a final process of the - devtool finish command, the state - of the standard layers and the upstream source is - restored so that you can build the recipe from those - areas rather than the workspace. - - You can use the devtool reset - command to put things back should you decide you - do not want to proceed with your work. - If you do use this command, realize that the source - tree is preserved. - - - - -
+ As a final process of the + devtool finish command, the state + of the standard layers and the upstream source is + restored so that you can build the recipe from those + areas rather than the workspace. + + You can use the devtool reset + command to put things back should you decide you + do not want to proceed with your work. + If you do use this command, realize that the source + tree is preserved. + + + + +
-
- Use <filename>devtool upgrade</filename> to Create a Version of the Recipe that Supports a Newer Version of the Software +
+ Use <filename>devtool modify</filename> to Modify the Source of an Existing Component - - The devtool upgrade command updates - an existing recipe so that you can build it for an updated - set of source files. - The command is flexible enough to allow you to specify - source code revision and versioning schemes, extract code into - or out of the devtool workspace, and - work with any source file forms that the fetchers support. - + + The devtool modify command prepares the + way to work on existing code that already has a recipe in + place. + The command is flexible enough to allow you to extract code, + specify the existing recipe, and keep track of and gather any + patch files from other developers that are + associated with the code. + - - Depending on your particular scenario, the arguments and options - you use with devtool upgrade form different - combinations. - The following diagram shows a common development flow - you would use with the devtool modify - command: - + + Depending on your particular scenario, the arguments and options + you use with devtool modify form different + combinations. + The following diagram shows common development flows + you would use with the devtool modify + command: + - - - + + + - - - Initiate the Upgrade: - The top part of the flow shows a typical scenario by which - you could use devtool upgrade. - The following conditions exist: - - The recipe exists in some layer external - to the devtool workspace. - - The source files for the new release - exist adjacent to the same location pointed to by - SRC_URI - in the recipe (e.g. a tarball with the new version - number in the name, or as a different revision in - the upstream Git repository). - - - A common situation is where third-party software has - undergone a revision so that it has been upgraded. - The recipe you have access to is likely in your own layer. - Thus, you need to upgrade the recipe to use the - newer version of the software: - + + + Preparing to Modify the Code: + The top part of the flow shows three scenarios by which + you could use devtool modify to + prepare to work on source files. + Each scenario assumes the following: + + The recipe exists in some layer external + to the devtool workspace. + + The source files exist upstream in an + un-extracted state or locally in a previously + extracted state. + + + The typical situation is where another developer has + created some layer for use with the Yocto Project and + their recipe already resides in that layer. + Furthermore, their source code is readily available + either upstream or locally. + + Left: + The left scenario represents a common situation + where the source code does not exist locally + and needs to be extracted. + In this situation, the source is extracted + into the default workspace location. + The recipe, in this scenario, is in its own + layer outside the workspace + (i.e. + meta-layername). + + + The following command identifies the recipe + and by default extracts the source files: + + $ devtool modify recipe + + Once devtoollocates the recipe, + it uses the + SRC_URI + variable to locate the source code and + any local patch files from other developers are + located. + + You cannot provide an URL for + srctree when using the + devtool modify command. + + With this scenario, however, since no + srctree argument exists, the + devtool modify command by default + extracts the source files to a Git structure. + Furthermore, the location for the extracted source is the + default area within the workspace. + The result is that the command sets up both the source + code and an append file within the workspace with the + recipe remaining in its original location. + + Middle: + The middle scenario represents a situation where + the source code also does not exist locally. + In this case, the code is again upstream + and needs to be extracted to some + local area as a Git repository. + The recipe, in this scenario, is again in its own + layer outside the workspace. + + The following command tells + devtool what recipe with + which to work and, in this case, identifies a local + area for the extracted source files that is outside + of the default workspace: + + $ devtool modify recipe srctree + + As with all extractions, the command uses + the recipe's SRC_URI to locate the + source files. + Once the files are located, the command by default + extracts them. + Providing the srctree + argument instructs devtool where + place the extracted source. + + Within workspace, devtool + creates an append file for the recipe. + The recipe remains in its original location but + the source files are extracted to the location you + provided with srctree. + + Right: + The right scenario represents a situation + where the source tree + (srctree) exists as a + previously extracted Git structure outside of + the devtool workspace. + In this example, the recipe also exists + elsewhere in its own layer. + + + The following command tells + devtool the recipe + with which to work, uses the "-n" option to indicate + source does not need to be extracted, and uses + srctree to point to the + previously extracted source files: + + $ devtool modify -n recipe srctree + + + + Once the command finishes, it creates only + an append file for the recipe in the workspace. + The recipe and the source code remain in their + original locations. + + + + Edit the Source: + Once you have used the devtool modify + command, you are free to make changes to the source + files. + You can use any editor you like to make and save + your source code modifications. + + Build the Recipe: + Once you have updated the source files, you can build + the recipe. + + Deploy the Build Output: + When you use the devtool build + command to build out your recipe, you probably want to see + if the resulting build output works as expected on target + hardware. + + This step assumes you have a previously built + image that is already either running in QEMU or + running on actual hardware. + Also, it is assumed that for deployment of the image + to the target, SSH is installed in the image and if + the image is running on real hardware that you have + network access to and from your development machine. + + You can deploy your build output to that target hardware by + using the devtool deploy-target command: + + $ devtool deploy-target recipe target + + The target is a live target machine + running as an SSH server. + + You can, of course, also deploy the image you build + using the devtool build-image command + to actual hardware. + However, devtool does not provide a + specific command that allows you to do this. + + + Finish Your Work With the Recipe: + The devtool finish command creates + any patches corresponding to commits in the local + Git repository, updates the recipe to point to them + (or creates a .bbappend file to do + so, depending on the specified destination layer), and + then resets the recipe so that the recipe is built normally + rather than from the workspace. + + $ devtool finish recipe layer + + + Any changes you want to turn into patches must be + committed to the Git repository in the source tree. + + + Because there is no need to move the recipe, + devtool finish either updates the + original recipe in the original layer or the command + creates a .bbappend in a different + layer as provided by layer. + + + As a final process of the + devtool finish command, the state + of the standard layers and the upstream source is + restored so that you can build the recipe from those + areas rather than the workspace. + + You can use the devtool reset + command to put things back should you decide you + do not want to proceed with your work. + If you do use this command, realize that the source + tree is preserved. + + + + +
+ +
+ Use <filename>devtool upgrade</filename> to Create a Version of the Recipe that Supports a Newer Version of the Software + + + The devtool upgrade command updates + an existing recipe so that you can build it for an updated + set of source files. + The command is flexible enough to allow you to specify + source code revision and versioning schemes, extract code into + or out of the devtool workspace, and + work with any source file forms that the fetchers support. + + + + Depending on your particular scenario, the arguments and options + you use with devtool upgrade form different + combinations. + The following diagram shows a common development flow + you would use with the devtool modify + command: + + + + + + + + + Initiate the Upgrade: + The top part of the flow shows a typical scenario by which + you could use devtool upgrade. + The following conditions exist: + + The recipe exists in some layer external + to the devtool workspace. + + The source files for the new release + exist adjacent to the same location pointed to by + SRC_URI + in the recipe (e.g. a tarball with the new version + number in the name, or as a different revision in + the upstream Git repository). + + + A common situation is where third-party software has + undergone a revision so that it has been upgraded. + The recipe you have access to is likely in your own layer. + Thus, you need to upgrade the recipe to use the + newer version of the software: + $ devtool upgrade -V version recipe - - By default, the devtool upgrade command - extracts source code into the sources - directory in the workspace. - If you want the code extracted to any other location, you - need to provide the srctree - positional argument with the command as follows: - + + By default, the devtool upgrade command + extracts source code into the sources + directory in the workspace. + If you want the code extracted to any other location, you + need to provide the srctree + positional argument with the command as follows: + $ devtool upgrade -V version recipe srctree - - Also, in this example, the "-V" option is used to specify - the new version. - If the source files pointed to by the - SRC_URI statement in the recipe are - in a Git repository, you must provide the "-S" option and - specify a revision for the software. + + Also, in this example, the "-V" option is used to specify + the new version. + If the source files pointed to by the + SRC_URI statement in the recipe are + in a Git repository, you must provide the "-S" option and + specify a revision for the software. - Once devtool locates the recipe, - it uses the SRC_URI variable to locate - the source code and any local patch files from other - developers are located. - The result is that the command sets up the source - code, the new version of the recipe, and an append file - all within the workspace. - - Resolve any Conflicts created by the Upgrade: - At this point, there could be some conflicts due to the - software being upgraded to a new version. - This would occur if your recipe specifies some patch files in - SRC_URI that conflict with changes - made in the new version of the software. - If this is the case, you need to resolve the conflicts - by editing the source and following the normal - git rebase conflict resolution - process. - Before moving onto the next step, be sure to resolve any - such conflicts created through use of a newer or different - version of the software. - - Build the Recipe: - Once you have your recipe in order, you can build it. - You can either use devtool build or - bitbake. - Either method produces build output that is stored - in - TMPDIR. - - Deploy the Build Output: - When you use the devtool build - command or bitbake to build out your - recipe, you probably want to see if the resulting build - output works as expected on target hardware. - - This step assumes you have a previously built - image that is already either running in QEMU or - running on actual hardware. - Also, it is assumed that for deployment of the image - to the target, SSH is installed in the image and if - the image is running on real hardware that you have - network access to and from your development machine. - - You can deploy your build output to that target hardware by - using the devtool deploy-target command: - + Once devtool locates the recipe, + it uses the SRC_URI variable to locate + the source code and any local patch files from other + developers are located. + The result is that the command sets up the source + code, the new version of the recipe, and an append file + all within the workspace. + + Resolve any Conflicts created by the Upgrade: + At this point, there could be some conflicts due to the + software being upgraded to a new version. + This would occur if your recipe specifies some patch files in + SRC_URI that conflict with changes + made in the new version of the software. + If this is the case, you need to resolve the conflicts + by editing the source and following the normal + git rebase conflict resolution + process. + Before moving onto the next step, be sure to resolve any + such conflicts created through use of a newer or different + version of the software. + + Build the Recipe: + Once you have your recipe in order, you can build it. + You can either use devtool build or + bitbake. + Either method produces build output that is stored + in + TMPDIR. + + Deploy the Build Output: + When you use the devtool build + command or bitbake to build out your + recipe, you probably want to see if the resulting build + output works as expected on target hardware. + + This step assumes you have a previously built + image that is already either running in QEMU or + running on actual hardware. + Also, it is assumed that for deployment of the image + to the target, SSH is installed in the image and if + the image is running on real hardware that you have + network access to and from your development machine. + + You can deploy your build output to that target hardware by + using the devtool deploy-target command: + $ devtool deploy-target recipe target - - The target is a live target machine - running as an SSH server. - You can, of course, also deploy the image you build - using the devtool build-image command - to actual hardware. - However, devtool does not provide a - specific command that allows you to do this. - - - Finish Your Work With the Recipe: - The devtool finish command creates - any patches corresponding to commits in the local - Git repository, updates the recipe to point to them - (or creates a .bbappend file to do - so, depending on the specified destination layer), and - then resets the recipe so that the recipe is built normally - rather than from the workspace. - + + The target is a live target machine + running as an SSH server. + You can, of course, also deploy the image you build + using the devtool build-image command + to actual hardware. + However, devtool does not provide a + specific command that allows you to do this. + + + Finish Your Work With the Recipe: + The devtool finish command creates + any patches corresponding to commits in the local + Git repository, updates the recipe to point to them + (or creates a .bbappend file to do + so, depending on the specified destination layer), and + then resets the recipe so that the recipe is built normally + rather than from the workspace. + $ devtool finish recipe layer - - - Any changes you want to turn into patches must be - committed to the Git repository in the source tree. - - Because there is no need to move the recipe, - devtool finish either updates the - original recipe in the original layer or the command - creates a .bbappend in a different - layer as provided by layer. - - As a final process of the - devtool finish command, the state - of the standard layers and the upstream source is - restored so that you can build the recipe from those - areas rather than the workspace. - - You can use the devtool reset - command to put things back should you decide you - do not want to proceed with your work. - If you do use this command, realize that the source - tree is preserved. - - - - + + + Any changes you want to turn into patches must be + committed to the Git repository in the source tree. + + Because there is no need to move the recipe, + devtool finish either updates the + original recipe in the original layer or the command + creates a .bbappend in a different + layer as provided by layer. + + As a final process of the + devtool finish command, the state + of the standard layers and the upstream source is + restored so that you can build the recipe from those + areas rather than the workspace. + + You can use the devtool reset + command to put things back should you decide you + do not want to proceed with your work. + If you do use this command, realize that the source + tree is preserved. + + + + +
-
-
- A Closer Look at <filename>devtool add</filename> - - - The devtool add command automatically creates a - recipe based on the source tree with which you provide it. - Currently, the command has support for the following: - - - Autotools (autoconf and - automake) - - - CMake - - - Scons - - - qmake - - - Plain Makefile - - - Out-of-tree kernel module - - - Binary package (i.e. "-b" option) - - - Node.js module - - - Python modules that use setuptools - or distutils - - - - - - Apart from binary packages, the determination of how a source tree - should be treated is automatic based on the files present within - that source tree. - For example, if a CMakeLists.txt file is found, - then the source tree is assumed to be using - CMake and is treated accordingly. - - In most cases, you need to edit the automatically generated - recipe in order to make it build properly. - Typically, you would go through several edit and build cycles - until you can build the recipe. - Once the recipe can be built, you could use possible further - iterations to test the recipe on the target device. - - - - - The remainder of this section covers specifics regarding how parts - of the recipe are generated. - - -
- Name and Version +
+ A Closer Look at <filename>devtool add</filename> - If you do not specify a name and version on the command - line, devtool add attempts to determine - the name and version of the software being built from - various metadata within the source tree. - Furthermore, the command sets the name of the created recipe - file accordingly. - If the name or version cannot be determined, the - devtool add command prints an error and - you must re-run the command with both the name and version - or just the name or version specified. + The devtool add command automatically creates a + recipe based on the source tree with which you provide it. + Currently, the command has support for the following: + + + Autotools (autoconf and + automake) + + + CMake + + + Scons + + + qmake + + + Plain Makefile + + + Out-of-tree kernel module + + + Binary package (i.e. "-b" option) + + + Node.js module + + + Python modules that use setuptools + or distutils + + - Sometimes the name or version determined from the source tree - might be incorrect. - For such a case, you must reset the recipe: - + Apart from binary packages, the determination of how a source tree + should be treated is automatic based on the files present within + that source tree. + For example, if a CMakeLists.txt file is found, + then the source tree is assumed to be using + CMake and is treated accordingly. + + In most cases, you need to edit the automatically generated + recipe in order to make it build properly. + Typically, you would go through several edit and build cycles + until you can build the recipe. + Once the recipe can be built, you could use possible further + iterations to test the recipe on the target device. + + + + + The remainder of this section covers specifics regarding how parts + of the recipe are generated. + + +
+ Name and Version + + + If you do not specify a name and version on the command + line, devtool add attempts to determine + the name and version of the software being built from + various metadata within the source tree. + Furthermore, the command sets the name of the created recipe + file accordingly. + If the name or version cannot be determined, the + devtool add command prints an error and + you must re-run the command with both the name and version + or just the name or version specified. + + + + Sometimes the name or version determined from the source tree + might be incorrect. + For such a case, you must reset the recipe: + $ devtool reset -n recipename - - After running the devtool reset command, - you need to run devtool add again and - provide the name or the version. - -
+ + After running the devtool reset command, + you need to run devtool add again and + provide the name or the version. + +
-
- Dependency Detection and Mapping +
+ Dependency Detection and Mapping - - The devtool add command attempts to - detect build-time dependencies and map them to other recipes - in the system. - During this mapping, the command fills in the names of those - recipes in the - DEPENDS - value within the recipe. - If a dependency cannot be mapped, then a comment is placed in - the recipe indicating such. - The inability to map a dependency might be caused because the - naming is not recognized or because the dependency simply is - not available. - For cases where the dependency is not available, you must use - the devtool add command to add an - additional recipe to satisfy the dependency and then come - back to the first recipe and add its name to - DEPENDS. - + + The devtool add command attempts to + detect build-time dependencies and map them to other recipes + in the system. + During this mapping, the command fills in the names of those + recipes in the + DEPENDS + value within the recipe. + If a dependency cannot be mapped, then a comment is placed in + the recipe indicating such. + The inability to map a dependency might be caused because the + naming is not recognized or because the dependency simply is + not available. + For cases where the dependency is not available, you must use + the devtool add command to add an + additional recipe to satisfy the dependency and then come + back to the first recipe and add its name to + DEPENDS. + - - If you need to add runtime dependencies, you can do so by - adding the following to your recipe: - + + If you need to add runtime dependencies, you can do so by + adding the following to your recipe: + RDEPENDS_${PN} += "dependency1 dependency2 ..." - - - The devtool add command often cannot - distinguish between mandatory and optional dependencies. - Consequently, some of the detected dependencies might - in fact be optional. - When in doubt, consult the documentation or the configure - script for the software the recipe is building for further - details. - In some cases, you might find you can substitute the - dependency for an option to disable the associated - functionality passed to the configure script. - - -
+ + + The devtool add command often cannot + distinguish between mandatory and optional dependencies. + Consequently, some of the detected dependencies might + in fact be optional. + When in doubt, consult the documentation or the configure + script for the software the recipe is building for further + details. + In some cases, you might find you can substitute the + dependency for an option to disable the associated + functionality passed to the configure script. + + +
-
- License Detection +
+ License Detection - - The devtool add command attempts to - determine if the software you are adding is able to be - distributed under a common open-source license and sets the - LICENSE - value accordingly. - You should double-check this value against the documentation - or source files for the software you are building and update - that LICENSE value if necessary. - + + The devtool add command attempts to + determine if the software you are adding is able to be + distributed under a common open-source license and sets the + LICENSE + value accordingly. + You should double-check this value against the documentation + or source files for the software you are building and update + that LICENSE value if necessary. + - - The devtool add command also sets the - LIC_FILES_CHKSUM - value to point to all files that appear to be license-related. - However, license statements often appear in comments at the top - of source files or within documentation. - Consequently, you might need to amend the - LIC_FILES_CHKSUM variable to point to one - or more of those comments if present. - Setting LIC_FILES_CHKSUM is particularly - important for third-party software. - The mechanism attempts to ensure correct licensing should you - upgrade the recipe to a newer upstream version in future. - Any change in licensing is detected and you receive an error - prompting you to check the license text again. - + + The devtool add command also sets the + LIC_FILES_CHKSUM + value to point to all files that appear to be license-related. + However, license statements often appear in comments at the top + of source files or within documentation. + Consequently, you might need to amend the + LIC_FILES_CHKSUM variable to point to one + or more of those comments if present. + Setting LIC_FILES_CHKSUM is particularly + important for third-party software. + The mechanism attempts to ensure correct licensing should you + upgrade the recipe to a newer upstream version in future. + Any change in licensing is detected and you receive an error + prompting you to check the license text again. + - - If the devtool add command cannot - determine licensing information, the - LICENSE value is set to "CLOSED" and the - LIC_FILES_CHKSUM value remains unset. - This behavior allows you to continue with development but is - unlikely to be correct in all cases. - Consequently, you should check the documentation or source - files for the software you are building to determine the actual - license. - -
+ + If the devtool add command cannot + determine licensing information, the + LICENSE value is set to "CLOSED" and the + LIC_FILES_CHKSUM value remains unset. + This behavior allows you to continue with development but is + unlikely to be correct in all cases. + Consequently, you should check the documentation or source + files for the software you are building to determine the actual + license. + +
-
- Adding Makefile-Only Software +
+ Adding Makefile-Only Software - - The use of make by itself is very common - in both proprietary and open source software. - Unfortunately, Makefiles are often not written with - cross-compilation in mind. - Thus, devtool add often cannot do very - much to ensure that these Makefiles build correctly. - It is very common, for example, to explicitly call - gcc instead of using the - CC - variable. - Usually, in a cross-compilation environment, - gcc is the compiler for the build host - and the cross-compiler is named something similar to - arm-poky-linux-gnueabi-gcc and might - require some arguments (e.g. to point to the associated sysroot - for the target machine). - + + The use of make by itself is very common + in both proprietary and open source software. + Unfortunately, Makefiles are often not written with + cross-compilation in mind. + Thus, devtool add often cannot do very + much to ensure that these Makefiles build correctly. + It is very common, for example, to explicitly call + gcc instead of using the + CC + variable. + Usually, in a cross-compilation environment, + gcc is the compiler for the build host + and the cross-compiler is named something similar to + arm-poky-linux-gnueabi-gcc and might + require some arguments (e.g. to point to the associated sysroot + for the target machine). + - - When writing a recipe for Makefile-only software, keep the - following in mind: - - - You probably need to patch the Makefile to use - variables instead of hardcoding tools within the - toolchain such as gcc and - g++. - - - The environment in which make runs - is set up with various standard variables for - compilation (e.g. CC, - CXX, and so forth) in a similar - manner to the environment set up by the SDK's - environment setup script. - One easy way to see these variables is to run the - devtool build command on the - recipe and then look in - oe-logs/run.do_compile. - Towards the top of this file you will see a list of - environment variables that are being set. - You can take advantage of these variables within the - Makefile. - - - If the Makefile sets a default for a variable using "=", - that default overrides the value set in the environment, - which is usually not desirable. - In this situation, you can either patch the Makefile - so it sets the default using the "?=" operator, or - you can alternatively force the value on the - make command line. - To force the value on the command line, add the - variable setting to - EXTRA_OEMAKE - or - PACKAGECONFIG_CONFARGS - within the recipe. - Here is an example using EXTRA_OEMAKE: - - EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'" - - In the above example, single quotes are used around the - variable settings as the values are likely to contain - spaces because required default options are passed to - the compiler. - - - Hardcoding paths inside Makefiles is often problematic - in a cross-compilation environment. - This is particularly true because those hardcoded paths - often point to locations on the build host and thus - will either be read-only or will introduce - contamination into the cross-compilation by virtue of - being specific to the build host rather than the target. - Patching the Makefile to use prefix variables or other - path variables is usually the way to handle this. - - - Sometimes a Makefile runs target-specific commands such - as ldconfig. - For such cases, you might be able to simply apply - patches that remove these commands from the Makefile. - - - -
- -
- Adding Native Tools - - - Often, you need to build additional tools that run on the - build host system as opposed to the target. - You should indicate this using one of the following methods - when you run devtool add: - - - Specify the name of the recipe such that it ends - with "-native". - Specifying the name like this produces a recipe that - only builds for the build host. - - - Specify the "‐‐also-native" option with the - devtool add command. - Specifying this option creates a recipe file that still - builds for the target but also creates a variant with - a "-native" suffix that builds for the build host. - - - - If you need to add a tool that is shipped as part of a - source tree that builds code for the target, you can - typically accomplish this by building the native and target - parts separately rather than within the same compilation - process. - Realize though that with the "‐‐also-native" option, you - can add the tool using just one recipe file. - - -
- -
- Adding Node.js Modules - - - You can use the devtool add command two - different ways to add Node.js modules: 1) Through - npm and, 2) from a repository or local - source. - - - - Use the following form to add Node.js modules through - npm: - - $ devtool add "npm://registry.npmjs.org;name=forever;version=0.15.1" - - The name and version parameters are mandatory. - Lockdown and shrinkwrap files are generated and pointed to by - the recipe in order to freeze the version that is fetched for - the dependencies according to the first time. - This also saves checksums that are verified on future fetches. - Together, these behaviors ensure the reproducibility and - integrity of the build. - Notes + + When writing a recipe for Makefile-only software, keep the + following in mind: - You must use quotes around the URL. - The devtool add does not require - the quotes, but the shell considers ";" as a splitter - between multiple commands. - Thus, without the quotes, - devtool add does not receive the - other parts, which results in several "command not - found" errors. + You probably need to patch the Makefile to use + variables instead of hardcoding tools within the + toolchain such as gcc and + g++. - In order to support adding - Node.js modules, a - nodejs recipe must be part of your - SDK in order to provide Node.js - itself. + The environment in which make runs + is set up with various standard variables for + compilation (e.g. CC, + CXX, and so forth) in a similar + manner to the environment set up by the SDK's + environment setup script. + One easy way to see these variables is to run the + devtool build command on the + recipe and then look in + oe-logs/run.do_compile. + Towards the top of this file you will see a list of + environment variables that are being set. + You can take advantage of these variables within the + Makefile. + + + If the Makefile sets a default for a variable using "=", + that default overrides the value set in the environment, + which is usually not desirable. + In this situation, you can either patch the Makefile + so it sets the default using the "?=" operator, or + you can alternatively force the value on the + make command line. + To force the value on the command line, add the + variable setting to + EXTRA_OEMAKE + or + PACKAGECONFIG_CONFARGS + within the recipe. + Here is an example using EXTRA_OEMAKE: + + EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'" + + In the above example, single quotes are used around the + variable settings as the values are likely to contain + spaces because required default options are passed to + the compiler. + + + Hardcoding paths inside Makefiles is often problematic + in a cross-compilation environment. + This is particularly true because those hardcoded paths + often point to locations on the build host and thus + will either be read-only or will introduce + contamination into the cross-compilation by virtue of + being specific to the build host rather than the target. + Patching the Makefile to use prefix variables or other + path variables is usually the way to handle this. + + + Sometimes a Makefile runs target-specific commands such + as ldconfig. + For such cases, you might be able to simply apply + patches that remove these commands from the Makefile. + +
+ +
+ Adding Native Tools + + + Often, you need to build additional tools that run on the + build host system as opposed to the target. + You should indicate this using one of the following methods + when you run devtool add: + + + Specify the name of the recipe such that it ends + with "-native". + Specifying the name like this produces a recipe that + only builds for the build host. + + + Specify the "‐‐also-native" option with the + devtool add command. + Specifying this option creates a recipe file that still + builds for the target but also creates a variant with + a "-native" suffix that builds for the build host. + + + + If you need to add a tool that is shipped as part of a + source tree that builds code for the target, you can + typically accomplish this by building the native and target + parts separately rather than within the same compilation + process. + Realize though that with the "‐‐also-native" option, you + can add the tool using just one recipe file. + + +
+ +
+ Adding Node.js Modules + + + You can use the devtool add command two + different ways to add Node.js modules: 1) Through + npm and, 2) from a repository or local + source. + + + + Use the following form to add Node.js modules through + npm: + + $ devtool add "npm://registry.npmjs.org;name=forever;version=0.15.1" + + The name and version parameters are mandatory. + Lockdown and shrinkwrap files are generated and pointed to by + the recipe in order to freeze the version that is fetched for + the dependencies according to the first time. + This also saves checksums that are verified on future fetches. + Together, these behaviors ensure the reproducibility and + integrity of the build. + Notes + + + You must use quotes around the URL. + The devtool add does not require + the quotes, but the shell considers ";" as a splitter + between multiple commands. + Thus, without the quotes, + devtool add does not receive the + other parts, which results in several "command not + found" errors. + + + In order to support adding + Node.js modules, a + nodejs recipe must be part of your + SDK in order to provide Node.js + itself. + + + + + + + As mentioned earlier, you can also add Node.js modules + directly from a repository or local source tree. + To add modules this way, use devtool add in + the following form: + + $ devtool add https://github.com/diversario/node-ssdp + + In this example, devtool fetches the specified + Git repository, detects that the code is Node.js code, fetches + dependencies using npm, and sets + SRC_URI + accordingly. + +
+
+ +
+ Working With Recipes + + + When building a recipe with devtool build the + typical build progression is as follows: + + + Fetch the source + + + Unpack the source + + + Configure the source + + + Compiling the source + + + Install the build output + + + Package the installed output + + + For recipes in the workspace, fetching and unpacking is disabled + as the source tree has already been prepared and is persistent. + Each of these build steps is defined as a function, usually with a + "do_" prefix. + These functions are typically shell scripts but can instead be written + in Python. + + + + If you look at the contents of a recipe, you will see that the + recipe does not include complete instructions for building the + software. + Instead, common functionality is encapsulated in classes inherited + with the inherit directive, leaving the recipe + to describe just the things that are specific to the software to be + built. + A base + class exists that is implicitly inherited by all recipes and provides + the functionality that most typical recipes need. + + + + The remainder of this section presents information useful when + working with recipes. + + +
+ Finding Logs and Work Files + + + When you are debugging a recipe that you previously created using + devtool add or whose source you are modifying + by using the devtool modify command, after + the first run of devtool build, you will + find some symbolic links created within the source tree: + oe-logs, which points to the directory in + which log files and run scripts for each build step are created + and oe-workdir, which points to the temporary + work area for the recipe. + You can use these links to get more information on what is + happening at each build step. + + + + These locations under oe-workdir are + particularly useful: + + image/: + Contains all of the files installed at the + do_install + stage. + Within a recipe, this directory is referred to by the + expression + ${D}. + + sysroot-destdir/: + Contains a subset of files installed within + do_install that have been put into the + shared sysroot. + For more information, see the + "Sharing Files Between Recipes" + section. + + packages-split/: + Contains subdirectories for each package produced by the + recipe. + For more information, see the + "Packaging" section. + + + +
+ +
+ Setting Configure Arguments + + + If the software your recipe is building uses GNU autoconf, + then a fixed set of arguments is passed to it to enable + cross-compilation plus any extras specified by + EXTRA_OECONF + or + PACKAGECONFIG_CONFARGS + set within the recipe. + If you wish to pass additional options, add them to + EXTRA_OECONF or + PACKAGECONFIG_CONFARGS. + Other supported build tools have similar variables + (e.g. + EXTRA_OECMAKE + for CMake, + EXTRA_OESCONS + for Scons, and so forth). + If you need to pass anything on the make + command line, you can use EXTRA_OEMAKE or the + PACKAGECONFIG_CONFARGS + variables to do so. + + + + You can use the devtool configure-help command + to help you set the arguments listed in the previous paragraph. + The command determines the exact options being passed, and shows + them to you along with any custom arguments specified through + EXTRA_OECONF or + PACKAGECONFIG_CONFARGS. + If applicable, the command also shows you the output of the + configure script's "‐‐help" option as a reference. + +
+ +
+ Sharing Files Between Recipes + + + Recipes often need to use files provided by other recipes on + the build host. + For example, an application linking to a common library needs + access to the library itself and its associated headers. + The way this access is accomplished within the extensible SDK is + through the sysroot. + One sysroot exists per "machine" for which the SDK is being built. + In practical terms, this means a sysroot exists for the target + machine, and a sysroot exists for the build host. + + + + Recipes should never write files directly into the sysroot. + Instead, files should be installed into standard locations + during the + do_install + task within the + ${D} + directory. + A subset of these files automatically go into the sysroot. + The reason for this limitation is that almost all files that go + into the sysroot are cataloged in manifests in order to ensure + they can be removed later when a recipe is modified or removed. + Thus, the sysroot is able to remain free from stale files. + +
+ +
+ Packaging + + + Packaging is not always particularly relevant within the + extensible SDK. + However, if you examine how build output gets into the final image + on the target device, it is important to understand packaging + because the contents of the image are expressed in terms of + packages and not recipes. + + + + During the + do_package + task, files installed during the + do_install + task are split into one main package, which is almost always named + the same as the recipe, and several other packages. + This separation is done because not all of those installed files + are always useful in every image. + For example, you probably do not need any of the documentation + installed in a production image. + Consequently, for each recipe the documentation files are separated + into a -doc package. + Recipes that package software that has optional modules or + plugins might do additional package splitting as well. + + + + After building a recipe you can see where files have gone by + looking in the oe-workdir/packages-split + directory, which contains a subdirectory for each package. + Apart from some advanced cases, the + PACKAGES + and + FILES + variables controls splitting. + The PACKAGES variable lists all of the + packages to be produced, while the FILES + variable specifies which files to include in each package, + using an override to specify the package. + For example, FILES_${PN} specifies the files + to go into the main package (i.e. the main package is named the + same as the recipe and + ${PN} + evaluates to the recipe name). + The order of the PACKAGES value is significant. + For each installed file, the first package whose + FILES value matches the file is the package + into which the file goes. + Defaults exist for both the PACKAGES and + FILES variables. + Consequently, you might find you do not even need to set these + variables in your recipe unless the software the recipe is + building installs files into non-standard locations. + +
+
+ +
+ Restoring the Target Device to its Original State + + + If you use the devtool deploy-target + command to write a recipe's build output to the target, and + you are working on an existing component of the system, then you + might find yourself in a situation where you need to restore the + original files that existed prior to running the + devtool deploy-target command. + Because the devtool deploy-target command + backs up any files it overwrites, you can use the + devtool undeploy-target to restore those files + and remove any other files the recipe deployed. + Consider the following example: + + $ devtool undeploy-target lighttpd root@192.168.7.2 + + If you have deployed multiple applications, you can remove them + all at once thus restoring the target device back to its + original state: + + $ devtool undeploy-target -a root@192.168.7.2 + + Information about files deployed to the target as well as any + backed up files are stored on the target itself. + This storage of course requires some additional space + on the target machine. + + The devtool deploy-target and + devtool undeploy-target command do not + currently interact with any package management system on the + target device (e.g. RPM or OPKG). + Consequently, you should not intermingle operations + devtool deploy-target and the package + manager operations on the target device. + Doing so could result in a conflicting set of files. +
+ +
+ Installing Additional Items Into the Extensible SDK - As mentioned earlier, you can also add Node.js modules - directly from a repository or local source tree. - To add modules this way, use devtool add in - the following form: + The extensible SDK typically only comes with a small number of tools + and libraries out of the box. + If you have a minimal SDK, then it starts mostly empty and is + populated on-demand. + However, sometimes you will need to explicitly install extra items + into the SDK. + If you need these extra items, you can first search for the items + using the devtool search command. + For example, suppose you need to link to libGL but you are not sure + which recipe provides it. + You can use the following command to find out: - $ devtool add https://github.com/diversario/node-ssdp - - In this example, devtool fetches the specified - Git repository, detects that the code is Node.js code, fetches - dependencies using npm, and sets - SRC_URI - accordingly. - -
-
- -
- Working With Recipes - - - When building a recipe with devtool build the - typical build progression is as follows: - - - Fetch the source - - - Unpack the source - - - Configure the source - - - Compiling the source - - - Install the build output - - - Package the installed output - - - For recipes in the workspace, fetching and unpacking is disabled - as the source tree has already been prepared and is persistent. - Each of these build steps is defined as a function, usually with a - "do_" prefix. - These functions are typically shell scripts but can instead be written - in Python. - - - - If you look at the contents of a recipe, you will see that the - recipe does not include complete instructions for building the - software. - Instead, common functionality is encapsulated in classes inherited - with the inherit directive, leaving the recipe - to describe just the things that are specific to the software to be - built. - A base - class exists that is implicitly inherited by all recipes and provides - the functionality that most typical recipes need. - - - - The remainder of this section presents information useful when - working with recipes. - - -
- Finding Logs and Work Files - - - When you are debugging a recipe that you previously created using - devtool add or whose source you are modifying - by using the devtool modify command, after - the first run of devtool build, you will - find some symbolic links created within the source tree: - oe-logs, which points to the directory in - which log files and run scripts for each build step are created - and oe-workdir, which points to the temporary - work area for the recipe. - You can use these links to get more information on what is - happening at each build step. - - - - These locations under oe-workdir are - particularly useful: - - image/: - Contains all of the files installed at the - do_install - stage. - Within a recipe, this directory is referred to by the - expression - ${D}. - - sysroot-destdir/: - Contains a subset of files installed within - do_install that have been put into the - shared sysroot. - For more information, see the - "Sharing Files Between Recipes" - section. - - packages-split/: - Contains subdirectories for each package produced by the - recipe. - For more information, see the - "Packaging" section. - - - -
- -
- Setting Configure Arguments - - - If the software your recipe is building uses GNU autoconf, - then a fixed set of arguments is passed to it to enable - cross-compilation plus any extras specified by - EXTRA_OECONF - or - PACKAGECONFIG_CONFARGS - set within the recipe. - If you wish to pass additional options, add them to - EXTRA_OECONF or - PACKAGECONFIG_CONFARGS. - Other supported build tools have similar variables - (e.g. - EXTRA_OECMAKE - for CMake, - EXTRA_OESCONS - for Scons, and so forth). - If you need to pass anything on the make - command line, you can use EXTRA_OEMAKE or the - PACKAGECONFIG_CONFARGS - variables to do so. - - - - You can use the devtool configure-help command - to help you set the arguments listed in the previous paragraph. - The command determines the exact options being passed, and shows - them to you along with any custom arguments specified through - EXTRA_OECONF or - PACKAGECONFIG_CONFARGS. - If applicable, the command also shows you the output of the - configure script's "‐‐help" option as a reference. - -
- -
- Sharing Files Between Recipes - - - Recipes often need to use files provided by other recipes on - the build host. - For example, an application linking to a common library needs - access to the library itself and its associated headers. - The way this access is accomplished within the extensible SDK is - through the sysroot. - One sysroot exists per "machine" for which the SDK is being built. - In practical terms, this means a sysroot exists for the target - machine, and a sysroot exists for the build host. - - - - Recipes should never write files directly into the sysroot. - Instead, files should be installed into standard locations - during the - do_install - task within the - ${D} - directory. - A subset of these files automatically go into the sysroot. - The reason for this limitation is that almost all files that go - into the sysroot are cataloged in manifests in order to ensure - they can be removed later when a recipe is modified or removed. - Thus, the sysroot is able to remain free from stale files. - -
- -
- Packaging - - - Packaging is not always particularly relevant within the - extensible SDK. - However, if you examine how build output gets into the final image - on the target device, it is important to understand packaging - because the contents of the image are expressed in terms of - packages and not recipes. - - - - During the - do_package - task, files installed during the - do_install - task are split into one main package, which is almost always named - the same as the recipe, and several other packages. - This separation is done because not all of those installed files - are always useful in every image. - For example, you probably do not need any of the documentation - installed in a production image. - Consequently, for each recipe the documentation files are separated - into a -doc package. - Recipes that package software that has optional modules or - plugins might do additional package splitting as well. - - - - After building a recipe you can see where files have gone by - looking in the oe-workdir/packages-split - directory, which contains a subdirectory for each package. - Apart from some advanced cases, the - PACKAGES - and - FILES - variables controls splitting. - The PACKAGES variable lists all of the - packages to be produced, while the FILES - variable specifies which files to include in each package, - using an override to specify the package. - For example, FILES_${PN} specifies the files - to go into the main package (i.e. the main package is named the - same as the recipe and - ${PN} - evaluates to the recipe name). - The order of the PACKAGES value is significant. - For each installed file, the first package whose - FILES value matches the file is the package - into which the file goes. - Defaults exist for both the PACKAGES and - FILES variables. - Consequently, you might find you do not even need to set these - variables in your recipe unless the software the recipe is - building installs files into non-standard locations. - -
-
- -
- Restoring the Target Device to its Original State - - - If you use the devtool deploy-target - command to write a recipe's build output to the target, and - you are working on an existing component of the system, then you - might find yourself in a situation where you need to restore the - original files that existed prior to running the - devtool deploy-target command. - Because the devtool deploy-target command - backs up any files it overwrites, you can use the - devtool undeploy-target to restore those files - and remove any other files the recipe deployed. - Consider the following example: - - $ devtool undeploy-target lighttpd root@192.168.7.2 - - If you have deployed multiple applications, you can remove them - all at once thus restoring the target device back to its - original state: - - $ devtool undeploy-target -a root@192.168.7.2 - - Information about files deployed to the target as well as any - backed up files are stored on the target itself. - This storage of course requires some additional space - on the target machine. - - The devtool deploy-target and - devtool undeploy-target command do not - currently interact with any package management system on the - target device (e.g. RPM or OPKG). - Consequently, you should not intermingle operations - devtool deploy-target and the package - manager operations on the target device. - Doing so could result in a conflicting set of files. - - -
- -
- Installing Additional Items Into the Extensible SDK - - - The extensible SDK typically only comes with a small number of tools - and libraries out of the box. - If you have a minimal SDK, then it starts mostly empty and is - populated on-demand. - However, sometimes you will need to explicitly install extra items - into the SDK. - If you need these extra items, you can first search for the items - using the devtool search command. - For example, suppose you need to link to libGL but you are not sure - which recipe provides it. - You can use the following command to find out: - $ devtool search libGL mesa A free implementation of the OpenGL API - - Once you know the recipe (i.e. mesa in this - example), you can install it: - + + Once you know the recipe (i.e. mesa in this + example), you can install it: + $ devtool sdk-install mesa - - By default, the devtool sdk-install assumes the - item is available in pre-built form from your SDK provider. - If the item is not available and it is acceptable to build the item - from source, you can add the "-s" option as follows: - + + By default, the devtool sdk-install assumes the + item is available in pre-built form from your SDK provider. + If the item is not available and it is acceptable to build the item + from source, you can add the "-s" option as follows: + $ devtool sdk-install -s mesa - - It is important to remember that building the item from source takes - significantly longer than installing the pre-built artifact. - Also, if no recipe exists for the item you want to add to the SDK, you - must instead add it using the devtool add command. - -
+ + It is important to remember that building the item from source takes + significantly longer than installing the pre-built artifact. + Also, if no recipe exists for the item you want to add to the SDK, you + must instead add it using the devtool add command. + +
-
- Updating the Extensible SDK +
+ Updating the 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 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. + - - To update your installed SDK, run the following: - + + To update your installed SDK, run the following: + $ 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: - + + 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: + $ 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 an + SDK installer that you would download and install. + + +
-
- Creating a Derivative SDK With Additional Components - - - You might need to produce an SDK that contains your own custom - libraries for sending to a third party (e.g., if you are a vendor with - customers needing to build their own software for the target platform). - If that is the case, then you can produce a derivative SDK based on - the currently installed SDK fairly easily. - Use these steps: - - If necessary, install an extensible SDK that - you want to use as a base for your derivative SDK. - - Source the environment script for the SDK. - - Add the extra libraries or other components - you want by using the devtool add - command. - - Run the devtool build-sdk - command. - - - The above procedure takes the recipes added to the workspace and - constructs a new SDK installer containing those recipes and the - resulting binary artifacts. - The recipes go into their own separate layer in the constructed - derivative SDK, leaving the workspace clean and ready for users - to add their own recipes. - -
+
+ Creating a Derivative SDK With Additional Components + + You might need to produce an SDK that contains your own custom + libraries for sending to a third party (e.g., if you are a vendor with + customers needing to build their own software for the target platform). + If that is the case, then you can produce a derivative SDK based on + the currently installed SDK fairly easily. + Use these steps: + + If necessary, install an extensible SDK that + you want to use as a base for your derivative SDK. + + Source the environment script for the SDK. + + Add the extra libraries or other components + you want by using the devtool add + command. + + Run the devtool build-sdk + command. + + + The above procedure takes the recipes added to the workspace and + constructs a new SDK installer containing those recipes and the + resulting binary artifacts. + The recipes go into their own separate layer in the constructed + derivative SDK, leaving the workspace clean and ready for users + to add their own recipes. + +