I am using yocto with the current kirkstone LTS release(for a long time). I tried to use the version information for recipes.
See: https://docs.yoctoproject.org/4.0.6/ref-manual/variables.html?highlight=preferred_version#term-PV
So I have a recipe like this: 'my-recipe_1.0.0.bb'
Now I want to install that recipe in this version in my image. So I have another recipe like 'image.bb' that installs the recipe with something like: 'IMAGE_INSTALL += "my-recipe".
Now I want the build to fail, if that recipe version does not exist. I use REQUIRED_VERSION for this, see: https://docs.yoctoproject.org/4.0.6/ref-manual/variables.html?highlight=preferred_version#term-REQUIRED_VERSION
So I added in my image.bb a line like this: 'REQUIRED_VERSION_my-recipe="1.0.0"'
This works perfectly fine and I can switch this way between different versions of my recipe.
Now comes the question: If I require a version of my recipe that does not exist, the documentation says I will get an error and an immediate build error. But instead, my build takes an existing recipe but not the one I required.
This leads to an unacceptable situation where my build build something I do not expect.
Now I wonder, if somebody has an idea what is going wrong.
I tried to use the REQUIRED_VERSION for different existing recipes. -> That worked as expected.
I tried to use the REQUIRED_VERSION for a not existing recipe. -> That did not work as expected. I got no build error.
Since the manual states that REQUIRED_VERSION "works in exactly the same manner as PREFERRED_VERSION" (except that it throws an error), maybe try using the forcevariable override:
REQUIRED_VERSION_my-recipe:forcevariable = "1.0.0"
Edit: Include this line in local.conf instead of the image.bb file for the expected behavior to take effect.
Hmm. What if you try including that line in local.conf instead of the
image.bb file? – thelummox Jan 13 at 16:11
Well, adding this to the local.conf raised the expected error. It even prints the available versions.
It is weird because local.conf is by definition not party of my layer but I can work with that.
Related
I am putting together a custom Linux image using Yocto. For now, it needs to include development tools and header files for numerous packages.
Thus far, this has worked perfectly fine by adding "-dev" packages as well. For example, I have added boost-dev, opencv-dev, and msgpack-c-dev. I am, however, running into errors with two recipes: (1) websocketpp_0.7.0.bb from meta-openembedded/meta-oe and (2) autobahn-cpp_18.4.1.bb which I have written. Adding -dev to either of these causes errors during the do_rootfs build phase.
Nothing provides websocketpp = 0.7.0-r0 needed by websocketpp-dev-0.7.0-r0
The non-dev recipe seem fine and I can see the work for both recipes includes all of the expected files. Any help is greatly appreciated.
To resolve such problem, You need to create empty websocketpp pacakge, with using - ALLOW_EMPTY.
ALLOW_EMPTY_${PN} = "1"
I am playing around with Microsoft's Q# library, and I've gone through the install, however the build is failing and I am having a tough time figuring out the problem. My first suspicion is Microsoft.Quantum.Canon
EXEC : error QS1001: Assembly E:\Projects\Quantum\Microsoft.Quantum.Canon\bin\Debug\Microsoft.Quantum.Canon.dll not found
I also have noticed Microsoft.Quantum.Canon.nuspec is missing. I've tried to do a Nuget.exe restore on the solutions but that did not work.
Has anyone worked through this?
It's been reported on GitHub already, although it appears to be intentional. See the comments in the .gitignore file:
# These files are generated by bootstrap from a .v.template (version template).
# Any changes must be done to the corresponding the .v.template file directly
Microsoft.Quantum.Canon/Microsoft.Quantum.Canon.nuspec
I can't find any info on this .v.template file, probably it's part of internal Microsoft build tooling. You can copy the template file and fill in the missing parameters if you wish, but the file not existing doesn't make the build fail , does it?
TL;DR: Is there a way to force to recompile a package every time an image is generated?
I have a bbappend with a do_deploy_append appending to a file and if I modify this step, the recipe will not be recompiled when generating an image using it. This can lead to errors pretty hard to ind. Bitbake assumes it has been unchanged. I have only 2 packages like this, very small.
Is there a parameter to force those package being cleaned and recompiled without manually do it?
I am using Yocto morty
Generally speaking, if you want a task to always be executed, you should use the [nostamp] varflag on this task, which should be set to "1". For example, if you want the recipe to be recompiled every time, you should add the below line to the package's recipe:
do_compile[nostamp] = "1"
To always execute the do_configure task, you should add the following line:
do_configure[nostamp] = "1"
This applies for any task that you need to always be executed. Have a look here for more information on nostamp variable flag: http://www.yoctoproject.org/docs/2.3.2/bitbake-user-manual/bitbake-user-manual.html
I am currently using yocto for building an embedded linux image for TI AM335x (I am using hob, since I find it more comfortable than using command-line).
I start using the recipe for building 'core-image-base' and here is the selection of packages which are included:
Now I would like to exclude the package alsa-utils-1.0.28-r0 from build, since it has some problems compiling for my target and I really do not need it... so, as far as I can understand, I have to remove all the dependencies which brought alsa-utils in (that is: alsa-state and packagegroup-base, looking at following screenshot):
So I move to Package groups tab and I remove packagegroup-base and then I remove alsa-state and alsa-utils from the Included recipes:
Now it seems that alsa-utils is there no more... but if I try to build the image, this is the result:
Why? Who is still bringing-in alsa-utils? What am I doing wrong? Is there a way (even command-line) to know why a package is brought-in by yocto?
Use
bitbake -g alsa-utils -u depexp
to display a dependency tree you should be able to see who's depending on it.
See the openembedded wiki.
I'm having trouble finding a simple example on how to use simplecov with rake/rspec.
Here's the repo I have setup: https://github.com/stensonb/simplecov-playground
If you clone this, and "bundle install", "rake coverage", you'll see 0/0 LOC...which is disappointing.
As the project sits now (8e5fa35983), I expect there to be 0/XX LOC (where XX is the actual lines of code I have...clearly more than zero - look at /lib/mytest.rb)
Things I've tried:
adding "require 'simplecov'" and "SimpleCov.start" to my spec_helper.rb
adding groups to the simplecov config
Anybody have a suggestion on how to get this thing to work?
Solved!
The major item I was missing was "requiring" my lib file in my test.
I had assumed simplecov would pull in ALL of my files by looking at the directory structure...but that doesn't appear to happen. It will only asses the codes explicitly loaded into the classpath (to use java parlance)...using "requires", or "load", or "include", I assume.
I'll push my solution back to this github location later today.