I need to build an image for a Xilinx FPGA. Followed these directions. Everything worked and I managed to build it. Now I need to add an extra layer. I thought all I needed to do is to modify .repo/manifests/default.xml (add this layer, https://github.com/sbabic/meta-swupdate/tree/rocko) and then execute
repo sync
but I'm getting errors saying that changes to multitude of files will be overwritten by a checkout (these are the files that were built).
So how do I add a layer to my current environment and rebuild with a new layer without actually rebuilding the whole thing?
cd ./sources/
git clone https://github.com/sbabic/meta-swupdate.git
cd ../conf/
vi ./bblayers.conf
add **{BSPDIR}/sources/meta-swupdate \** before (")
vi ./local.conf
add **IMAGE_INSTALL_append = " swupdate" **
bitbake
How to add Layer example: https://www.youtube.com/watch?v=3HsaoVqX7dg
Related
I am using teamcity to build my Unity3d projects. When I am selecting branch in custom build or when build is triggered from "not master branch" git performs clean, and it removes my Library folder. I need to persist this folder because it is a cache that builds a huge amount of time. When I stay on master, everything is fine and this cache is reused. How can I do this? I want this folder to be shared between my branches.
I tried to create multiple VSC roots, but it copies my repo for every branch. I also disabled all "clean" options that I found in settings. But nothing helps
You could try one of these:
In VCS Root settings you could set Clean Policy to Never. It sets whether and when TeamCity should exec git clean in working dir. Default value is "On branch change" which I guess is your case. But it means that you should manually clean your working dir from build artifacts. For more information see here
You could use Unity Accelerator
You could backup your Library folder in the end of every build and restore in the beginning of the next one
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).
I am trying to add new c file in place of file that already comes after downloading the package from git.Tried bbappend but the original file is still there.also modified src_uri += file://fileone.c but that is also not overwriting file.
Any suggestions would be of great help
Regards
Mayank
This is where devtool modify can be very helpful if you're using the jethro (2.0) release or later. Assuming you have already sourced the environment setup script:
devtool modify <recipename>
It will tell you where it has extracted the source - cd into that directory.
Make the changes to the file that you want - which could be overwriting it completely.
git commit -a to commit your changes
devtool update-recipe <recipename> -a /path/to/your/custom/layer (assuming you want to create a bbappend in a custom layer, otherwise just omit the -a and path to apply the changes to the original recipe instead).
If you are completely finished, you can devtool reset <recipename> to put everything back to building completely from the metadata.
So the original C file is part of the release tarball (or git, or wherever the release comes from) and you want to replace that file with your own before configure and compile happen?
Replacing the whole file is just a special case of any smaller changes you might want to do the source files, so just do what you would do in those cases: create a patch the replaces the file and add the patch with SRC_URI += file://replace-file-with-my-file.patch.
I use this work flow (in the project source directory, e.g. poky/build/tmp/work/corei7-64-poky-linux/my-project):
# initialize git (only if this is not a git repo already)
git init
git add *
git commit -m "original code"
# <--- here you should replace the file
git commit -a -m "Replace file with a better file"
git format-patch -1
Now you should have a patch file that you can copy into the proper recipe directory.
Is it possible to have more than one source checkout step in BuildBot? I can't find any explicit documentation of this, but it appears that doing a source checkout in BuildBot also changes the current working directory to the checkout directory, which means it's unclear where one would "go" to checkout from another repository and then run a script that uses both.
Consider the example at http://buildbot.net/buildbot/docs/0.8.1/BuildFactory.html:
From the steps, it appears that a CVS checkout is performed and then make build is run. That is two steps in BuildBot, which is convenient.
However, if you were do to the equivalent from the command line, it would be three steps:
cvs co $CVSROOT
cd directory_that_was_created
make build
Where does the cd directory_that_was_created step happen in BuildBot?
But more importantly, what if I want to have two source.CVS (well, really source.Git) steps? What directory am I in after I run the second step? Does the second repo end up in a subdirectory of the first repo?
With Git, it seems like I could make one a submodule of the other to ensure that they would both get checked out in one step, though I would prefer not to do that, if possible.
OK, I figured this out. I did not realize that there is the concept of a "workdir" associated with each step that indicates where the "work" happens. The default workdir for all steps is a directory named build.
On http://buildbot.net/buildbot/docs/latest/manual/cfg-buildsteps.html under Source Checkout -> Common Parameters -> workdir, it does acknowledge that source steps are special "in that they perform some operations outside of the workdir (like creating the workdir itself)."
This explains why there is no explicit step that corresponds to a cd command in my above example. To solve my problem, I created two Git steps, each with its own workdir value. This is followed by subsequent ShellCommand steps that call into the appropriate directory, knowing that the two workdir directories will be siblings of one another.
I've got a project in a git repository that uses some custom (and so far unversioned) setup scripts for the build environment etc. I'd like to put these under version control (hopefully git) but keep them versioned separate from the project itself, while still living in the base directory of the project - I've considered options like local branches but these seem to have the problem that switch back to master (or any other "real" branch) will throw away the working copies of the setup scripts.
I'm on Windows using msysgit so I've got a few tools to play with; does anyone have a recommendation or solution?
If you really need them separate from your main git repo while still living directly within it, you could try:
creating a new repo with those script within it
and:
adding that new repo as a submodule to your repo. Except:
a/ those scripts won't live directly in the base directory, but in a subfolder representing the submodule
b/ you need of course to not publish (push) that new repo, in order for other cloning your main repo to not get those setup files
or:
merging that new repo into your main repo (with the subtree project), but:
you need to split back your project to get rid of those files
for a project with a large history, and with frequent push, that step (the split) can be long and cumbersome.
I would consider a simpler solution, involving some evolution to your current setup files:
a private repo (as in "not pushed") with those setup files
environment variables with the path of your main git repo in order for your setup files (which would not be directly within the base directory of said main repo) to do their job in the right directory (like beginning for instance with a 'cd right_main_git_repo_dir').
I want to share an additional solution and some samples from which to start.
I've has a similar problem in attempting to build Mozilla Firefox with Buildbot -- I need to have some files in the root folder (namely the .mozconfig file and some helper scripts) and I wanted to version them separately.
My solution is as follow:
checkout the Firefox code from the Mercurial repository;
checkout an additional repository with the additional file I need;
before starting the build, I copy these file to the folder with the Firefox code.
This approach is implemented in the following repositories:
buildconfig-mozilla-central: it contains the Buildbot configuration, which
pulls both repositories
copies the files from the scripts repository
and start the build;
buildscripts-mozilla-central: the repository with the build configuration and helper scripts.
Please note that the code might not be well factored (for example the paths) but it should be a good starting point.
This procedure is tailored for Firefox, but it can be applied to any repository.