Git is an even more powerful tool that allows you to capture source code changes without having a clean source tree. This section outlines the typical workflow you can use to modify temporary source code, test changes, and then preserve the changes in the form of a patch all using Git. For general information on Git as it is used in the Yocto Project, see the "Git" section.
Follow these general steps:
Find the Source Code: The temporary source code used by the OpenEmbedded build system is kept in the Build Directory. See the "Finding the Temporary Source Code" section to learn how to locate the directory that has the temporary source code for a particular package.
Change Your Working Directory:
You need to be in the directory that has the temporary source code.
That directory is defined by the
S
variable.
If needed, initialize a Git Repository: If the recipe you are working with does not use a Git fetcher, you need to set up a Git repository as follows:
$ git init $ git add * $ git commit -m "initial revision"
The above Git commands initialize a Git repository that is based on the files in your current working directory, stage all the files, and commit the files. At this point, your Git repository is aware of all the source code files. Any edits you now make to files can be committed later and will be tracked by Git.
Edit the Files: Make your changes to the temporary source code.
Test Your Changes:
Once you have modified the source code, the easiest way
to test your changes is by calling the
do_compile
task as shown in the
following example:
$ bitbake -c compile -f <name_of_package>
The -f
or --force
option forces the specified task to execute.
If you find problems with your code, you can just keep editing and
re-testing iteratively until things work as expected.
-c clean
, -c cleansstate
,
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.
See the List of Files You Changed:
Use the git status
command to see what files you have actually edited.
The ability to have Git track the files you have changed is an advantage that this
workflow has over the Quilt workflow.
Here is the Git command to list your changed files:
$ git status
Stage the Modified Files:
Use the git add
command to stage the changed files so they
can be committed as follows:
$ git add file1.c file2.c file3.c
Commit the Staged Files and View Your Changes:
Use the git commit
command to commit the changes to the
local repository.
Once you have committed the files, you can use the git log
command to see your changes:
$ git commit -m "<commit-summary-message>" $ git log
commit-summary-message
.Generate the Patch:
Once the changes are committed, use the git format-patch
command to generate a patch file:
$ git format-patch -1
Specifying "-1" causes Git to generate the patch file for the most recent commit.
At this point, the patch file has all your edits made
to the file1.c
, file2.c
, and
file3.c
files.
You can find the resulting patch file in the current directory and it
is named according to the git commit
summary line.
The patch file ends with .patch
.
Copy the Patch File:
For simplicity, copy the patch file into a directory named files
,
which you can create in the same directory that holds the recipe
(.bb
) file or the
append (.bbappend
) file.
Placing the patch here guarantees that the OpenEmbedded build system will find
the patch.
Next, add the patch into the
SRC_URI
of the recipe.
Here is an example:
SRC_URI += "file://0001-<commit-summary-message>.patch"
Increment the Recipe Revision Number:
Finally, don't forget to 'bump' the
PR
value in the recipe since the resulting packages have changed.