I have a yocto project where I added some recipes and some of the functions in them are crucial when building (the functions consist inly some links creations, some files "equilibristics"). Although when first build all is done and the sstate_cache is saved to shared/sstate_cache so that those recipes are mentioned executed. When I make some changings on building system, also delete some of the built files or the hole build dir and rerun the build, bitbake does not execute the recipes.
The only solution is to:
bitbake -c cleanall <list_of_my_recipes_to_be_rerun>
So I have to explicitly clean the cache to tell bitbake to rerun them.
So my questions are:
Is there some way to explicitly set the recipe to be executed no matter what the shared cache saved on it?
Or maybe save the state locally in the build dir?
Or maybe tell bitbake not to save state for the recipe?
You could set BB_DONT_CACHE = "1" in the recipe, rerun the recipe with the -C option, or make the task checksum depend upon these things which you're changing so it automatically rebuilds when you change them. You could also just clean the recipe and then use the --no-setscene to bitbake.
Easy way:
$ bitbake <recipe> -C unpack
This builds recipe but forces unpack to rerun, which means everything else has to rerun too.
However if the recipe doesn't work with sstate then that is a problem with your recipe.
Is there some way to explicitly set the recipe to be executed no matter what the shared cache saved on it?
To force a recipe to run regardless of what is in the shared-state cache (or anything else),
pass the -f | --force option to the bitbake command, e.g.
bitbake -f [other_options...] recipe_name ...
See the bitbake commmandline options in the manual.
Related
I'm trying to change the alsa-utils recipe to add a configure option for the state dir. I need to move it to '/etc'.
I used devtool to modify, edit-recipe, and build without any issues. When I try to update-recipe, I get the following message:
INFO: No patches or local source files needed updating
And it's not creating the .bbappend for my recipe changes. I haven't changed anything in the source directory.
Any ideas of what I'm doing wrong?
update-recipe creates a proper directory tree with .bbappend and .patch files in your layer only if you have commited any changes to the source directory.
If you don't want to create .bbappend manually, commit some changes to the source code you've got via devtool, run update-recipe, remove any reference to the patch file in your newly created recipe.
How can I rebuild the image after making some modifications to driver source code?
I have tried bitbake -f -c compile and bitbake but I coudn't find the modified settings in the driver. Can someone tell me how can i rebuild the image with the modified code.
I guess that you want to re-generate the whole image, don't you? If so, you can try the following commands to ensure that bitbake won't use the sstate cache:
bitbake image-name -c cleansstate && bitbake image-name
In the case you just want to rebuild the kernel, substitute image-name by virtual/kernel (or the name of whatever recipe you want to rebuild).
Note that the do_cleansstate task is going to remove the recipe ${WORKDIR}!
For further information: https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-tasks-cleansstate
In the case you're doing such modifications directly in the ${WORKDIR}, which you shouldn't unless you're testing, the execution of the following command would be enough:
bitbake virtual/kernel -f -c compile
or
bitbake virtual/kernel -C compile (to invalidate the stamps and force all tasks starting from do_compile)
Since changes in ${WORKDIR} will be rewritten after cleaning, you can put your code to external workspace by command devtool modify <recipe-name>
By default your recipe code will be put into tmp/workspace/source/ directory
Now you can freely modify your code and simply build using bitbake <recipe-name> as usual.
When your modification are OK you can easily save your changes as patches to original recipe code (as far as it is likely open-source and downloaded):
commit your changes in your workspace
in order to automatically create patches and append they to recipe use command devtool recipe-update -a <layer-path> <recipe-name>
If you did your modifications not directly in the ${WORKDIR}, you have to set the SRCREV to your new hash and increase your PR. Then enter the command
bitbake <image-name>
Which compiles the one package again and creates the new image with your changes.
If you did your changes in the ${WORKDIR}, please add, commit and push them to your repository and then follow my steps above. This is the cleanest solution.
The command suggested by other solutions:
bitbake <image-name> -c cleansstate
Will cause all of the packages to rebuild, which can take very long if you don't have an sstate mirror.
I made some changes on u-boot source /tmp/work/beaglebone_my-poky-linux-gnueabi/u-boot/1_2018.07-r0/git
When I rebuild with bitbake core-image-minimal. Bitbake is not overwriting images in the path /images/.
Then I used clean, cleansstate, but both of them deleted all my changes in the u-boot/1_2018.07-r0/git directory.
What is the most efficient way to customize the u-boot and kernel?
Thank you.
Changing a recipe's fetched sources directory is not enough to permanently modify source code in Yocto as it is just a temporary working directory that, as you experienced, can be cleaned and all.
Changes to Yocto recipes sources can be made by:
modifying the source code in the working directory
creating a patch for your changes
change/create some recipe to apply your patch
the patch will be applied in build time
This section describes the process of modifying source code and creating a patch:
https://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html#modifying-source-code
This section describes the process of creating an extra layer and a recipe for the patches you created in order to apply them during build time:
https://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html#modifying-source-code
To create distribution in perl I use Module::Build. And generate meta files by command: ./Build distmeta
Creating Makefile.PL
Creating README using Pod::Text
Creating LICENSE file
Created META.yml and META.json
At some point I decide to delete all autogenerated files. I run ./Build distclean
Cleaning up build files
Cleaning up configuration files
But metafiles are left: README, LICENSE
Is there a command to cleanup those files too?
The META files are removed because those are purely generated, but README and LICENSE are often customized, so they can't be safely removed or overwritten.
If you don't customize README and LICENSE, and if you insist on having a means of removing them, there is a solution if you use git. Don't add the files to the repository (which is made easy by adding them to .gitignore), and use git clean -dfx (instead of ./Build distclean) to freshen your directory.
Is it good practice to edit source code in poky/build/tmp/work directory ? because if we accidentally cleansstate ,the changes will be erased.
Alternatively we can edit source code in "files" directory along with recipe file but since mostly code here is in zipped form due to large number of files , so we will need to unzip and zip again just to change one line of code.
So what is best way to edit source code in yocto ?
If your question is about permanent changes, then Dan's answer is the one to follow. I.e. add a <recipe name>.bbappend to the recipe in your own layer, in which you add
SRC_URI += "file://mypatch1.patch \
file://mypatch2.patch \
"
enumerating all the patches you need.
If there's a large number of patches, it might make sense to fork the upstream repository, and maintain your own branch in your fork. In that case, you'll likely want to reference your own repository, instead of either the upstream repository or tarball.
OTOH, if your question was more about work-in-progress; then sure, doing it in oky/build/tmp/workoky/build/tmp/work/xxxx will work. (And quite likely, it's what most people have been doing for a long time).
However, there's a much better way in recent releases (from 1.8, fido). The new tool is called devtool. You can use it as follows:
devtool modify -x <recipe-name> <path-to-unpack-source>
unpacks the source and creates a new bbappend to build from the unpacked source. It also creates a git repo in the source directory.
Now you can modify the source. You can test-build your modified source by running devtool build <recipe-name>. Once you're satisfied, use git add ... and git commit to commit your changes to the local repo. Once you've commited the changes to the local repo, you can run:
devtool update-recipe <recipe-name>
to update the recipe in question. When you're satisfied, you can run devtool reset <recipe-name> to remove the temporary bbappend.
See also: Yocto manual on modifying source code
If you are continuously "patching" a given package manually, I would recommend you to look at implementing a .bbappend file in a separate layer which applies your patch using the do_patch function (http://www.yoctoproject.org/docs/2.0/mega-manual/mega-manual.html#patching-dev-environment).