diff options
author | Scott Rifenbark <scott.m.rifenbark@intel.com> | 2012-02-16 15:22:44 -0600 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2012-03-08 12:07:57 -0800 |
commit | 452d2764c9d650d7b7d90579062133b2835b010c (patch) | |
tree | 55dd43c4459ab99f439b54f73ea5d9f0f51c53ef /documentation | |
parent | 797fabdbab6f22d095000a3592671382705fd4b6 (diff) | |
download | poky-452d2764c9d650d7b7d90579062133b2835b010c.tar.gz |
documentation/dev-manual/dev-manual-common-tasks.xml: re-write to 4.4
Complete re-write to the "Modifying Temporary Source Code" section,
Section 4.4. This strategy now comprises telling the user where
this temporary source code is, how to change it within a Quilt
workflow, and how to change it within a Git workflow.
I consulted with Paul Eggleton quite a bit to come to this conclusion
that the section needed more attention.
(From yocto-docs rev: 8c6c80121c1eeb1ec6f79e1efb6aa27aa9fd111f)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation')
-rw-r--r-- | documentation/dev-manual/dev-manual-common-tasks.xml | 318 |
1 files changed, 231 insertions, 87 deletions
diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml index be639f76b8..5fcc69cbd0 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/documentation/dev-manual/dev-manual-common-tasks.xml | |||
@@ -746,48 +746,51 @@ so that there are some definite steps on how to do this. I need more detail her | |||
746 | </section> | 746 | </section> |
747 | </section> | 747 | </section> |
748 | 748 | ||
749 | <section id="usingpoky-modifing-packages"> | 749 | <section id="modifying-temporary-source-code"> |
750 | <title>Modifying Package Source Code</title> | 750 | <title>Modifying Temporary Source Code</title> |
751 | 751 | ||
752 | <para> | 752 | <para> |
753 | This section describes how to modify package source code in the | 753 | Although the Yocto Project is typically used to build software, you might |
754 | <link linkend='yocto-project-build-directory'>Yocto Project's Build Directory</link> | 754 | find it helpful during development to modify the temporary source code used by recipes |
755 | and also how to then use | 755 | to build packages. |
756 | <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink> to manage | 756 | For example, suppose you are developing a patch and you need to experiment a bit |
757 | the resulting patches. | 757 | to figure out your solution. |
758 | After you have initially built the package, you can iteratively tweak the | ||
759 | source code, which is located in the | ||
760 | <link linkend='yocto-project-build-directory'>Yocto Project's Build Directory</link>, and then | ||
761 | you can force a re-compile and quickly test your altered code. | ||
762 | Once you settle on a solution, you can then preserve your changes in the form of | ||
763 | patches. | ||
764 | You can accomplish these steps all within either a | ||
765 | <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink> or | ||
766 | <link linkend='git'>Git</link> workflow. | ||
758 | </para> | 767 | </para> |
759 | 768 | ||
760 | <section id='working-with-source-code-in-the-build-directory'> | 769 | <section id='finding-the-temporary-source-code'> |
761 | <title>Working with Source Code in the Build Directory</title> | 770 | <title>Finding the Temporary Source Code</title> |
762 | 771 | ||
763 | <para> | 772 | <para> |
764 | Although the Yocto Project is typically used to build software, you might | 773 | During a build, the unpacked temporary source code used by recipes |
765 | find it helpful during development to modify the temporary package source code | 774 | to build packages is available in the Yocto Project build directory as |
766 | found within the Yocto Project's Build Directory. | 775 | defined by the |
767 | For example, suppose you are developing a patch and you need to experiment a bit | 776 | <filename><ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-S'>S</ulink></filename> variable: |
768 | to figure out your solution. | 777 | <literallayout class='monospaced'> |
769 | After you have initially built the package, you can iteratively tweak the | 778 | S = ${WORKDIR}/${PN}-${PV} |
770 | source code, which is located in the Yocto Project build directory, and then | 779 | </literallayout> |
771 | you can force a re-compile and test your altered code. | ||
772 | Once you settle on a solution, you can then copy the updated source code | ||
773 | to its more permanent location. | ||
774 | </para> | 780 | </para> |
775 | 781 | ||
776 | <para> | 782 | <para> |
777 | During a build, this temporary source code is available in the Yocto | 783 | The actual location within the build directory for the temporary source code |
778 | Project build directory, which is defined by the | 784 | depends on the package name and the architecture of the target device. |
779 | <filename><ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-TMPDIR'>TMPDIR</ulink></filename> variable. | 785 | Here is the temporary source code location for packages whose targets are not |
780 | The actual location within the build directory for the package source code | 786 | device-dependent: |
781 | is defined by the | ||
782 | <filename><ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-WORKDIR'>WORKDIR</ulink></filename> | ||
783 | variable and depends on the package name and the architecture of the target device. | ||
784 | Here is the source code location for packages that are not target device-dependent: | ||
785 | <literallayout class='monospaced'> | 787 | <literallayout class='monospaced'> |
786 | ${TMPDIR}/work/${PACKAGE_ARCH}-poky-${TARGET_OS}/${PN}-${PV}-${PR} | 788 | ${TMPDIR}/work/${PACKAGE_ARCH}-poky-${TARGET_OS}/${PN}-${PV}-${PR} |
787 | </literallayout> | 789 | </literallayout> |
790 | Let's look at an example. | ||
788 | Assuming a Yocto Project Files top-level directory named <filename>poky</filename> | 791 | Assuming a Yocto Project Files top-level directory named <filename>poky</filename> |
789 | and a default Yocto Project build directory of <filename>poky/build</filename>, | 792 | and a default Yocto Project build directory of <filename>poky/build</filename>, |
790 | the following is the temporary package source code location for the | 793 | the following is the temporary source code location for the |
791 | <filename>acl</filename> package: | 794 | <filename>acl</filename> package: |
792 | <literallayout class='monospaced'> | 795 | <literallayout class='monospaced'> |
793 | ~/poky/build/tmp/work/i586-poky-linux/acl-2.2.51-r3 | 796 | ~/poky/build/tmp/work/i586-poky-linux/acl-2.2.51-r3 |
@@ -795,96 +798,237 @@ so that there are some definite steps on how to do this. I need more detail her | |||
795 | </para> | 798 | </para> |
796 | 799 | ||
797 | <para> | 800 | <para> |
798 | If your package is target device-dependent, the source code location varies slightly: | 801 | If your package is dependent on the target device, the temporary |
802 | source code location varies slightly: | ||
799 | <literallayout class='monospaced'> | 803 | <literallayout class='monospaced'> |
800 | ${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}-${PV}-${PR} | 804 | ${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}-${PV}-${PR} |
801 | </literallayout> | 805 | </literallayout> |
802 | Again, assuming a Yocto Project Files top-level directory named <filename>poky</filename> | 806 | Again, assuming a Yocto Project Files top-level directory named <filename>poky</filename> |
803 | and a default Yocto Project build directory of <filename>poky/build</filename>, the | 807 | and a default Yocto Project build directory of <filename>poky/build</filename>, the |
804 | following is the temporary package source code location for the | 808 | following is the temporary source code location for the |
805 | <filename>acl</filename> package that is being built for a MIPS-based device: | 809 | <filename>acl</filename> package that is being built for a MIPS-based device: |
806 | <literallayout class='monospaced'> | 810 | <literallayout class='monospaced'> |
807 | ~/poky/build/tmp/work/mips-poky-linux/acl-2.2.51-r2 | 811 | ~/poky/build/tmp/work/mips-poky-linux/acl-2.2.51-r2 |
808 | </literallayout> | 812 | </literallayout> |
809 | </para> | 813 | </para> |
810 | 814 | ||
811 | <para> | 815 | <note> |
812 | Once you have modified the package source code, the easiest way to test your changes | 816 | To better understand how the Yocto Project build system resolves directories during the |
813 | is by calling the <filename>compile</filename> task as shown in the following example: | 817 | build process, see the glossary entries for the |
814 | <literallayout class='monospaced'> | 818 | <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-WORKDIR'>WORKDIR</ulink>, |
815 | $ bitbake -c compile -f <name_of_package> | 819 | <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-TMPDIR'>TMPDIR</ulink>, |
816 | </literallayout> | 820 | <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-TOPDIR'>TOPDIR</ulink>, |
817 | </para> | 821 | <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-PACKAGE_ARCH'>PACKAGE_ARCH</ulink>, |
822 | <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-TARGET_OS'>TARGET_OS</ulink>, | ||
823 | <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-PN'>PN</ulink>, | ||
824 | <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-PV'>PV</ulink>, | ||
825 | and | ||
826 | <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-PR'>PR</ulink> | ||
827 | variables in the Yocto Project Reference Manual. | ||
828 | </note> | ||
818 | 829 | ||
819 | <para> | 830 | <para> |
820 | The <filename>-f</filename> or <filename>--force</filename> | 831 | Now that you know where to locate the temporary source files, you can use a |
821 | option forces re-execution of the specified task. | 832 | Quilt or Git workflow to make your edits, test the changes, and preserve the |
822 | You can call other tasks this way as well. | 833 | changes in the form of patches. |
823 | <note>All the modifications you make to the temporary package source code | ||
824 | disappear once you <filename>-c clean</filename> or | ||
825 | <filename>-c cleanall</filename> with BitBake for the package. | ||
826 | Modifications will also disappear if you use the <filename>rm_work</filename> | ||
827 | feature as described in the | ||
828 | "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section | ||
829 | of the Yocto Project Quick Start. | ||
830 | </note> | ||
831 | </para> | 834 | </para> |
832 | </section> | 835 | </section> |
833 | 836 | ||
834 | <section id="usingpoky-modifying-packages-quilt"> | 837 | <section id="using-a-quilt-workflow"> |
835 | <title>Modifying Package Source Code with Quilt</title> | 838 | <title>Using a Quilt Workflow</title> |
836 | 839 | ||
837 | <para> | 840 | <para> |
838 | By default, the Yocto Project build system (Poky) uses | ||
839 | <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink> | 841 | <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink> |
840 | to manage patches while executing the <filename>do_patch</filename> task. | 842 | is a powerful tool that allows you to capture source code changes without having |
841 | Quilt is a powerful tool that you can use to track all modifications to package sources. | 843 | a clean source tree. |
842 | </para> | 844 | This section outlines the typical workflow you can use to modify temporary source code, |
843 | 845 | test changes, and then preserve the changes in the form of a patch all using Quilt. | |
844 | <para> | ||
845 | Before modifying source code, it is important to notify Quilt so it can track the changes | ||
846 | into a new patch file. | ||
847 | To create a new patch, use <filename>quilt new</filename> as below: | ||
848 | <literallayout class='monospaced'> | ||
849 | $ quilt new NAME-OF-PATCH.patch | ||
850 | </literallayout> | ||
851 | </para> | 846 | </para> |
852 | 847 | ||
853 | <para> | 848 | <para> |
854 | After creating the patch, add all the files you will be modifying into that patch | 849 | Follow these general steps: |
855 | as follows: | 850 | <orderedlist> |
856 | <literallayout class='monospaced'> | 851 | <listitem><para><emphasis>Find the Source Code:</emphasis> |
857 | $ quilt add file1 file2 file3 | 852 | The temporary source code used by the Yocto Project build system is kept in the |
858 | </literallayout> | 853 | Yocto Project build directory. |
854 | See the | ||
855 | "<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>" | ||
856 | section to learn how to locate temporary source code for a | ||
857 | particular package.</para></listitem> | ||
858 | <listitem><para><emphasis>Change Your Working Directory:</emphasis> | ||
859 | You need to be in the directory that has the temporary source code. | ||
860 | That directory is defined by the | ||
861 | <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-S'>S</ulink> | ||
862 | variable.</para></listitem> | ||
863 | <listitem><para><emphasis>Notify Quilt:</emphasis> | ||
864 | Before modifying source code, it is important to notify Quilt so it can track changes | ||
865 | into a new patch file. | ||
866 | To create a new patch file, use <filename>quilt new</filename> as below: | ||
867 | <literallayout class='monospaced'> | ||
868 | $ quilt new my_changes.patch | ||
869 | </literallayout></para></listitem> | ||
870 | <listitem><para><emphasis>Add Files:</emphasis> | ||
871 | After creating the patch, add the files you will be modifying into that patch | ||
872 | as follows: | ||
873 | <literallayout class='monospaced'> | ||
874 | $ quilt add file1.c file2.c file3.c | ||
875 | </literallayout></para></listitem> | ||
876 | <listitem><para><emphasis>Edit the Files:</emphasis> | ||
877 | Make the changes to the temporary source code.</para></listitem> | ||
878 | <listitem><para><emphasis>Test Your Changes:</emphasis> | ||
879 | Once you have modified the source code, the easiest way to test your changes | ||
880 | is by calling the <filename>compile</filename> task as shown in the following example: | ||
881 | <literallayout class='monospaced'> | ||
882 | $ bitbake -c compile -f <name_of_package> | ||
883 | </literallayout> | ||
884 | The <filename>-f</filename> or <filename>--force</filename> | ||
885 | option forces re-execution of the specified task. | ||
886 | If you find problems with your code, you can just keep editing and | ||
887 | re-testing iteratively until things work as expected. | ||
888 | <note>All the modifications you make to the temporary source code | ||
889 | disappear once you <filename>-c clean</filename> or | ||
890 | <filename>-c cleanall</filename> with BitBake for the package. | ||
891 | Modifications will also disappear if you use the <filename>rm_work</filename> | ||
892 | feature as described in the | ||
893 | "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" | ||
894 | section of the Yocto Project Quick Start. | ||
895 | </note></para></listitem> | ||
896 | <listitem><para><emphasis>Generate the Patch:</emphasis> | ||
897 | Once your changes work as expected, you need to use Quilt to generate the final patch that | ||
898 | contains all your modifications. | ||
899 | <literallayout class='monospaced'> | ||
900 | $ quilt refresh | ||
901 | </literallayout> | ||
902 | At this point the <filename>my_changes.patch</filename> file has all your edits made | ||
903 | to the <filename>file1.c</filename>, <filename>file2.c</filename>, and | ||
904 | <filename>file3.c</filename> files.</para> | ||
905 | <para>You can find the resulting patch file in the <filename>patches/</filename> | ||
906 | subdirectory of the source (<filename>S</filename>) directory.</para></listitem> | ||
907 | <listitem><para><emphasis>Copy the Patch File:</emphasis> | ||
908 | For future builds, you should copy the patch file into the | ||
909 | <link linkend='yocto-project-files'>Yocto Project Files</link> metadata and add it | ||
910 | into the | ||
911 | <filename><ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-SRC_URI'>SRC_URI</ulink></filename> | ||
912 | of the recipe. | ||
913 | Here is an example: | ||
914 | <literallayout class='monospaced'> | ||
915 | SRC_URI += "file://my_changes.patch" | ||
916 | </literallayout></para></listitem> | ||
917 | <listitem><para><emphasis>Increment the Package Revision Number:</emphasis> | ||
918 | Finally, don't forget to 'bump' the | ||
919 | <filename><ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-PR'>PR</ulink></filename> | ||
920 | value in the same recipe since the resulting packages have changed.</para></listitem> | ||
921 | </orderedlist> | ||
859 | </para> | 922 | </para> |
923 | </section> | ||
860 | 924 | ||
925 | <section id='using-a-git-workflow'> | ||
926 | <title>Using a Git Workflow</title> | ||
861 | <para> | 927 | <para> |
862 | You can now start editing the source code. | 928 | Git is an even more powerful tool that allows you to capture source code changes without having |
863 | Once you are done editing, you need to use Quilt to generate the final patch that | 929 | a clean source tree. |
864 | contains all your modifications. | 930 | This section outlines the typical workflow you can use to modify temporary source code, |
865 | <literallayout class='monospaced'> | 931 | test changes, and then preserve the changes in the form of a patch all using Git. |
866 | $ quilt refresh | 932 | For general information on Git as it is used in the Yocto Project, see the |
867 | </literallayout> | 933 | "<link linkend='git'>Git</link>" section. |
868 | </para> | 934 | </para> |
869 | 935 | ||
870 | <para> | 936 | <para> |
871 | You can find the resulting patch file in the | 937 | The steps in this section assume that you have already created a local Git repository of |
872 | <filename>patches/</filename> subdirectory of the source | 938 | the <link linkend='yocto-project-files'>Yocto Project Files</link> and have checked them |
873 | (<filename><ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-S'>S</ulink></filename>) directory. | 939 | out into an appropriate local working branch. |
874 | For future builds, you should copy the patch into the | 940 | If you need more explanation on setting up the Yocto Project Files, see the |
875 | <link linkend='yocto-project-files'>Yocto Project Files</link> metadata and add it | 941 | "<link linkend='getting-setup'>Getting Setup</link>" section. |
876 | into the | 942 | Also, if you need information on Git workflows in general, see the |
877 | <filename><ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-SRC_URI'>SRC_URI</ulink></filename> of the recipe. | 943 | <link linkend='workflows'>Workflows</link> section. |
878 | Here is an example: | ||
879 | <literallayout class='monospaced'> | ||
880 | SRC_URI += "file://NAME-OF-PATCH.patch" | ||
881 | </literallayout> | ||
882 | </para> | 944 | </para> |
883 | 945 | ||
884 | <para> | 946 | <para> |
885 | Finally, don't forget to 'bump' the | 947 | Follow these general steps: |
886 | <filename><ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-PR'>PR</ulink></filename> | 948 | <orderedlist> |
887 | value in the same recipe since the resulting packages have changed. | 949 | <listitem><para><emphasis>Find the Source Code:</emphasis> |
950 | The temporary source code used by the Yocto Project build system is kept in the | ||
951 | Yocto Project build directory. | ||
952 | See the | ||
953 | "<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>" | ||
954 | section to learn how to locate temporary source code for a | ||
955 | particular package.</para></listitem> | ||
956 | <listitem><para><emphasis>Change Your Working Directory:</emphasis> | ||
957 | You need to be in the directory that has the temporary source code. | ||
958 | That directory is defined by the | ||
959 | <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-S'>S</ulink> | ||
960 | variable.</para></listitem> | ||
961 | <listitem><para><emphasis>Edit the Files:</emphasis> | ||
962 | Make the changes to the temporary source code.</para></listitem> | ||
963 | <listitem><para><emphasis>Test Your Changes:</emphasis> | ||
964 | Once you have modified the source code, the easiest way to test your changes | ||
965 | is by calling the <filename>compile</filename> task as shown in the following example: | ||
966 | <literallayout class='monospaced'> | ||
967 | $ bitbake -c compile -f <name_of_package> | ||
968 | </literallayout> | ||
969 | The <filename>-f</filename> or <filename>--force</filename> | ||
970 | option forces re-execution of the specified task. | ||
971 | If you find problems with your code, you can just keep editing and | ||
972 | re-testing iteratively until things work as expected. | ||
973 | <note>All the modifications you make to the temporary source code | ||
974 | disappear once you <filename>-c clean</filename> or | ||
975 | <filename>-c cleanall</filename> with BitBake for the package. | ||
976 | Modifications will also disappear if you use the <filename>rm_work</filename> | ||
977 | feature as described in the | ||
978 | "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" | ||
979 | section of the Yocto Project Quick Start. | ||
980 | </note></para></listitem> | ||
981 | <listitem><para><emphasis>See the List of Files You Changed:</emphasis> | ||
982 | Use the Git <filename>status</filename> command to see what files you have actually edited. | ||
983 | The ability to have Git track the files you have changed is an advantage that this | ||
984 | workflow has over the Quilt workflow. | ||
985 | Here is the Git command to list your changed files: | ||
986 | <literallayout class='monospaced'> | ||
987 | $ git status | ||
988 | </literallayout></para></listitem> | ||
989 | <listitem><para><emphasis>Stage the Modified Files:</emphasis> | ||
990 | Use the Git <filename>add</filename> command to stage the changed files so they | ||
991 | can be committed as follows: | ||
992 | <literallayout class='monospaced'> | ||
993 | $ git add file1.c file2.c file3.c | ||
994 | </literallayout></para></listitem> | ||
995 | <listitem><para><emphasis>Commit the Staged Files and View Your Changes:</emphasis> | ||
996 | Use the Git <filename>commit</filename> command to commit the changes to the | ||
997 | local repository. | ||
998 | Once you have committed the files, you can use the Git <filename>log</filename> | ||
999 | command to see your changes: | ||
1000 | <literallayout class='monospaced'> | ||
1001 | $ git commit | ||
1002 | $ git log | ||
1003 | </literallayout></para></listitem> | ||
1004 | <listitem><para><emphasis>Generate the Patch:</emphasis> | ||
1005 | Once the changes are committed, you use the Git <filename>format-patch</filename> | ||
1006 | command to generate a patch file: | ||
1007 | <literallayout class='monospaced'> | ||
1008 | $ git format-patch HEAD~1 | ||
1009 | </literallayout> | ||
1010 | The <filename>HEAD~1</filename> part of the command causes Git to generate the | ||
1011 | patch file for the most recent commit.</para> | ||
1012 | <para>At this point, the patch file has all your edits made | ||
1013 | to the <filename>file1.c</filename>, <filename>file2.c</filename>, and | ||
1014 | <filename>file3.c</filename> files. | ||
1015 | You can find the resulting patch file in the <filename>patches/</filename> | ||
1016 | subdirectory of the source (<filename>S</filename>) directory.</para></listitem> | ||
1017 | <listitem><para><emphasis>Copy the Patch File:</emphasis> | ||
1018 | For future builds, you should copy the patch file into the | ||
1019 | <link linkend='yocto-project-files'>Yocto Project Files</link> metadata and add it | ||
1020 | into the | ||
1021 | <filename><ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-SRC_URI'>SRC_URI</ulink></filename> | ||
1022 | of the recipe. | ||
1023 | Here is an example: | ||
1024 | <literallayout class='monospaced'> | ||
1025 | SRC_URI += "file://my_changes.patch" | ||
1026 | </literallayout></para></listitem> | ||
1027 | <listitem><para><emphasis>Increment the Package Revision Number:</emphasis> | ||
1028 | Finally, don't forget to 'bump' the | ||
1029 | <filename><ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-PR'>PR</ulink></filename> | ||
1030 | value in the same recipe since the resulting packages have changed.</para></listitem> | ||
1031 | </orderedlist> | ||
888 | </para> | 1032 | </para> |
889 | </section> | 1033 | </section> |
890 | </section> | 1034 | </section> |