diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index 1199669ab0..327289b54b 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -748,128 +748,143 @@ so that there are some definite steps on how to do this. I need more detail her
Modifying Package Source Code
-
- Although the Yocto Project is typically used to build software, you might
- find it helpful during development to modify the temporary package source code
- found within the
- Yocto Project's Build Directory.
- For example, suppose you are developing a patch and you need to experiment a bit
- to figure out your solution.
- After you have initially built the package, you can iteratively tweak the
- source code, which is located in the Yocto Project build directory, and then
- you can force a re-compile and test your altered code.
- Once you settle on a solution, you can then copy the updated source code
- to its more permanent location.
-
- During a build, this temporary source code is available in the Yocto
- Project build directory, which is defined by the
- TMPDIR variable.
- The actual location within the build directory for the package source code
- is defined by the
- WORKDIR
- variable and depends on the package name and the architecture of the target device.
- Here is the source code location for packages that are not target device-dependent:
-
+ This section describes how to modify package source code in the
+ Yocto Project's Build Directory
+ and also how to then use
+ Quilt to manage
+ the resulting patches.
+
+
+
+ Working with Source Code in the Build Directory
+
+
+ Although the Yocto Project is typically used to build software, you might
+ find it helpful during development to modify the temporary package source code
+ found within the Yocto Project's Build Directory.
+ For example, suppose you are developing a patch and you need to experiment a bit
+ to figure out your solution.
+ After you have initially built the package, you can iteratively tweak the
+ source code, which is located in the Yocto Project build directory, and then
+ you can force a re-compile and test your altered code.
+ Once you settle on a solution, you can then copy the updated source code
+ to its more permanent location.
+
+
+
+ During a build, this temporary source code is available in the Yocto
+ Project build directory, which is defined by the
+ TMPDIR variable.
+ The actual location within the build directory for the package source code
+ is defined by the
+ WORKDIR
+ variable and depends on the package name and the architecture of the target device.
+ Here is the source code location for packages that are not target device-dependent:
+
${TMPDIR}/work/${PACKAGE_ARCH}-poky-${TARGET_OS}/${PN}-${PV}-${PR}
-
- Assuming a Yocto Project Files top-level directory named poky
- and a default Yocto Project build directory of poky/build,
- the following is the temporary package source code location for the
- acl package:
-
+
+ Assuming a Yocto Project Files top-level directory named poky
+ and a default Yocto Project build directory of poky/build,
+ the following is the temporary package source code location for the
+ acl package:
+
~/poky/build/tmp/work/i586-poky-linux/acl-2.2.51-r3
-
-
+
+
-
- If your package is target device-dependent, the source code location varies slightly:
-
+
+ If your package is target device-dependent, the source code location varies slightly:
+
${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}-${PV}-${PR}
-
- Again, assuming a Yocto Project Files top-level directory named poky
- and a default Yocto Project build directory of poky/build, the
- following is the temporary package source code location for the
- acl package that is being built for a MIPS-based device:
-
+
+ Again, assuming a Yocto Project Files top-level directory named poky
+ and a default Yocto Project build directory of poky/build, the
+ following is the temporary package source code location for the
+ acl package that is being built for a MIPS-based device:
+
~/poky/build/tmp/work/mips-poky-linux/acl-2.2.51-r2
-
-
+
+
-
- Once you have modified the package source code, the easiest way to test your changes
- is by calling the compile task as shown in the following example:
-
+
+ Once you have modified the package source code, the easiest way to test your changes
+ is by calling the compile task as shown in the following example:
+
$ bitbake -c compile -f <name_of_package>
-
-
+
+
-
- The -f or --force
- option forces re-execution of the specified task.
- You can call other tasks this way as well.
- All the modifications you make to the temporary package source code
- disappear once you -c clean or
- -c cleanall with BitBake for the package.
- Modifications will also disappear if you use the rm_work
- feature as described in the
- "Building an Image" section
- of the Yocto Project Quick Start.
-
-
-
+
+ The -f or --force
+ option forces re-execution of the specified task.
+ You can call other tasks this way as well.
+ All the modifications you make to the temporary package source code
+ disappear once you -c clean or
+ -c cleanall with BitBake for the package.
+ Modifications will also disappear if you use the rm_work
+ feature as described in the
+ "Building an Image" section
+ of the Yocto Project Quick Start.
+
+
+
-
- Modifying Package Source Code with Quilt
+
+ Modifying Package Source Code with Quilt
-
- By default Poky uses Quilt
- to manage patches in the do_patch task.
- This is a powerful tool that you can use to track all modifications to package sources.
-
+
+ By default, the Yocto Project build system (Poky) uses
+ Quilt
+ to manage patches while executing the do_patch task.
+ Quilt is a powerful tool that you can use to track all modifications to package sources.
+
-
- Before modifying source code, it is important to notify Quilt so it can track the changes
- into the new patch file:
-
+
+ Before modifying source code, it is important to notify Quilt so it can track the changes
+ into the new patch file:
+
$ quilt new NAME-OF-PATCH.patch
-
-
+
+
-
- After notifying Quilt, add all modified files into that patch:
-
+
+ After notifying Quilt, add all modified files into that patch:
+
$ quilt add file1 file2 file3
-
-
+
+
-
- You can now start editing.
- Once you are done editing, you need to use Quilt to generate the final patch that
- will contain all your modifications.
-
+
+ You can now start editing the source code.
+ Once you are done editing, you need to use Quilt to generate the final patch that
+ contains all your modifications.
+
$ quilt refresh
-
-
+
+
-
- You can find the resulting patch file in the
- patches/ subdirectory of the source
- (S) directory.
- For future builds, you should copy the patch into the Yocto Project metadata and add it into the
- SRC_URI of a recipe.
- Here is an example:
-
+
+ You can find the resulting patch file in the
+ patches/ subdirectory of the source
+ (S) directory.
+ For future builds, you should copy the patch into the
+ Yocto Project Files metadata and add it
+ into the
+ SRC_URI of the recipe.
+ Here is an example:
+
SRC_URI += "file://NAME-OF-PATCH.patch"
-
-
+
+
-
- Finally, don't forget to 'bump' the
- PR
- value in the same recipe since the resulting packages have changed.
-
+
+ Finally, don't forget to 'bump' the
+ PR
+ value in the same recipe since the resulting packages have changed.
+
+