I have a third-party Yocto layer which provides a recipe (let's call it recipe.bb) which references a local include file using require recipe.inc).
I have then created a custom layer and I would like to "replace" the included file recipe.inc with a custom version of it, provided by me. Is it possible? I've already tried to put my own recipe.inc in my folder and then using FILESEXTRAPATHS_prepend := "${THISDIR}:" in my recipe_%.bbappend but it does not work and the original recipe.inc is still included...
Is there a way for doing that?
No, it's not possible to override an .inc-file like that.
If you really need to do that, you could just as well copy recipe.bb into your own layer as well. Normally, the .inc file has all the logics, and the .bb-file only has the version specific stuff. Thus, replacing the .inc file would basically be equal to writing a new recipe.
What are you trying to do, that would require changing all the logics?
Are you sure that it's not enough to add a .bbappend file in your own layer, and override a smaller selection of tasks / variables from the .inc-file?
Related
In bitbake, are inheritances transferable between include files when they are added with require keyword? Or do we need to reuse inherit keyword over and over again in each of the include files? I'm using bitbake to built images with Yocto.
exampleA.inc file
inherit exampleC
exampleB.inc file
require exampleA.inc
In that case, if I want exampleB.inc to be inherited from exampleC as well, do I need to specify it in this file?
Assume that the exampleC is a bbclass file.
TLDR: one inherit statement is enough.
require and include just insert the content of the specified file at the current position in the recipe. This results in the same outcome, as if you had written the whole content of your .inc file into the recipe. Multiple layers of include / require should not change that. This means, that not the .inc file inherits from exanpleC, but rather the recipe, which requires said .inc file.
I also ran some quick tests to confirm the theory, and it all seems to work.
Do not be deterred by the BitBake documentation stating:
[...] you can use the inherit directive to inherit the functionality of a class (.bbclass). BitBake only supports this directive when used within recipe and class files (i.e. .bb and .bbclass).
This does not mean, that it does not work in .inc files, but rather that it will not work for configuration files.
in yocto imagebuildscripts there is a config variable named "IMAGE_FEATURES" i want to create a custom Imagefeature.
I searched my yocto installation which runs poky for existing imagefeatures but i wasn't able to find it.
IMAGE_FEATURES is a bit special, as its basically being hardcoded into image.bbclass.
Generally you are way better off creating custom DISTRO_FEATURES, and triggering on them whereever needed. See packagegroup-core-boot as an example of a recipe changing behaviour based on DISTRO_FEATURE in various places.
Usage wise there is little difference, the only thing you can't do is set DISTRO_FEATURES in the image recipe. If that is your actual need, then you probably should pour the new functionality in a custom image class the includes and extends image.bbclassm and call it myimage.bbclass (or similar).
EDIT:
Initially, I referred to the dropbear recipe as an example that triggers behaviour based on systemd being set as DISTRO_FEATURE. This is technically correct (and it was the first recipe that came to my mind), but probably confusing as there is a dropbear spedific IMAGE_FEATURE too.
I have a custom layer in project. This gets shared with colleagues.
My distro (poky) it uses a older version of alsa. This gets downloaded on initial setup of the build area. I would like to 'replace' that version of alsa with a later version and do this within my custom layer, so that they don't have to edit/replace recipes in poky.
What's the best way to do this? If I just download the newer recipe and include it in my layer (matching the file system names) will it automatically use the later version or is there something else I need to do?
The way you proceeded is the right way, you should add new recipes/bbappend files on your own layer(s), you shouldn't modify Yocto's base layers nor third-party layers by default. Nevertheless, since you want to add a newer version of an existing recipe, you should keep in mind that:
You have to check the priority of your own layer and the priority of the layer that contains the original recipe. Yocto will pick the recipe of the higher priority layer, no matter if it is a newer version or not (ignoring PV). For further information, search for BBFILE_PRIORITY in the Yocto Project Reference Manual. (You can also see a list of all configured layers along with their priorities with the command bitbake-layers show-layers)
In the case of both layers having the same priority, Yocto will build the recipe with the highest PV (you can check/set this value inside your recipe or in its filename recipename_pv.bb). Alternatively, if you wish to select another version rather than the one that is being currently built, you can just set the variable PREFERRED_VERSION_recipename = desiredPV in your distro.conf or local.conf file.
I have a legacy java project that we have been moving to buildr/artifactory from ant/jars in svn.
The primary code is in the default (src/main/java) folder, but we have a few external source paths, for various tests that we can't move into the default folder, but we want to have access with it.
Currently, when adding a new library/regenerating IDE fields, it does not pick up these source paths, and I can't find a succinct discussion in the buildr manual for how to actually add them, rather than re-adding everything manually in eclipse (which just gets wiped out on the next regen).
Any idea how to have multiple source paths get picked up explicitly by buildr so that the idea/eclipse targets generate properly?
There are two ways that I know will work with IDEA. The second one might also work with Eclipse, while the first is specific to the idea task.
The IDEA-specific solution:
define 'proj' do
# ...
iml.main_source_directories << _('src/other')
end
iml also has test_source_directories and excluded_directories arrays you can append to.
The possibly eclipse-compatible solution, with more background than you probably want:
The iml object gets its default values for the main and test source directory arrays from project.compile.sources and project.test.compile.sources (slight simplification; resources are considered also). Buildr defines these .sources project attributes from the layout, so instead of explicitly appending to the iml attributes, you could use a custom layout for your project that includes your special source paths. That might work with the eclipse task, but I haven't tried it.
I'm trying to come up with a way to make it easy to switch out our "mock" data services and our live ones. Basically, we'll have live servers with real web services, but for whatever reason, a developer may want to load data from static files (file urls).
I figured I would solve this problem by creating categories that override the methods that fetch the data, thus leaving original code untouched (it has no concept of the "mock" data). I don't want to litter my code with #ifdef.
I can put an #ifdef at the very beginning of each file that has categories in it, and I can set a custom flag in the configuration settings, but I'd rather just have a way to include or exclude the files depending on the configuration. Is that possible? How do you solve this problem?
See http://lists.apple.com/archives/xcode-users/2009/Jun/msg00153.html
The trick is to define EXCLUDED_SOURCE_FILE_NAMES in the configuration you want to exclude the files from, and set the value of that custom build setting to a list of the file names (or a pattern that matches those, and only those, file names).
I would recommend creating two targets one of which has the mock categories included and another one which does not.
When you want to test, just build the target containing the mock categories. Everything else can remain identical.
If you would like to add a file but do not wont to compile it. Go to (for all your targets) project>build phases>compile source and take out the file that you do not want to compile.