i have added dependencies through DEPENDS +=. While do_prepare_recipe_sysroot, what order does it follow while copying to recipe-sysroot?
How I can enforce this order?
eg:
for recipeA
DEPENDS += "recipeB recipeC"
DEPENDS += "recipeD"
where as recipeB depends on recipeD.
Here recipeC and recipeD both populate header.h. which one will be include in the recipe-sysroot.
You can't do this. Dependencies ordering is automatically done by Yocto. Same file cannot be provided by different recipes. You will get error like below,
Exception: FileExistsError: [Errno 17] File exists:
So you need to fix up the path. For example, if recipe C is for Application X, then you should try usr/include/X/header.h and usr/include/Y/header.h for recipe D or you should name is differently.
As far as dependency is concerned, you don't need to worry about the ordering. Yocto automatically parses and identifies which one to compile first in it's task queue.
Related
I have an application A that depends on library B. But library B can only build for the target, i.e. non-native. Also, I need to build A for both the host and the target. Unfortunately, I get an error like this:
Nothing PROVIDES B-native (but A-native DEPENDS or otherwise requires it)
In the recipe for A, I have tried numerous variations of
DEPENDS_append = "B" DEPENDS_remove = "B-native" DEPENDS-${PN}-native_remove = "B-native"
to no avail.
I'm sure there is a simple way to do this but I haven't found the correct combination of commands yet.
I have a recipe that does a check during parsing. What I would like to do is instead of issuing a warning or stopping with an error, I would like to make yocto completely ignore the recipe as if it was never there. It could still error out if some other recipe RDEPENDS on it, but otherwise parsing would be successful.
Is this possible to do?
EDIT: I don't see a way to do it.
But you can "hide" specific recipe(s) using the BBMASK variable. The value is regexp for masking specific files or paths. You can also mask a whole directory.
We are using that mechanism and the variable is set in configuration file (distro configuration in our case, but it may be in a different configuration file).
You can find more information in the documentation for that variable: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-BBMASK
Some examples copied from the linked documentation:
BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/"
BBMASK += "/meta-oe/recipes-support/"
BBMASK += "/meta-foo/.*/openldap"
BBMASK += "opencv.*\.bbappend"
BBMASK += "lzma"
When bitbake launches, it first parses everything it can in order to figure out what does it have and are there any obvious errors. Only after this stage it analyzes what have you asked it to do. So if you have syntax errors there is no other way to avoid it except don't add the layer that contains invalid recipe to bblayers.conf.
Yes, you can, by raising bb.parse.SkipRecipe exception
python() {
...
if ... :
raise bb.parse.SkipRecipe("Message")
...
}
I don't find it well documented, but google does return some assuring results for this.
I have a custom machine layer based on https://github.com/jumpnow/meta-wandboard.
I've upgraded the kernel to 4.8.6 and want to add X11 to the image.
I'm modifying to image recipe (console-image.bb).
Since wandboard is based on i.MX6, I want to include the xf86-video-imxfb-vivante package from meta-fsl-arm.
However, it fails complaining about inability to build kernel-module-imx-gpu-viv. I believe that happens because xf86-video-imxfb-vivante DEPENDS on imx-gpu-viv which in turn RDEPENDS on kernel-module-imx-gpu-viv.
I realize that those dependencies have been created with meta-fsl-arm BSP and vanilla Poky distribution. But those things are way outdated for wandboard, hence I am using the custom machine layer with modern kernel.
The kernel is configured to include the Vivante DRM module and I really don't want the kernel-module-imx-gpu-viv package to be built.
Is there a way to exclude it from RDEPENDS? Can I somehow swear my health to the build system that I will take care of this specific run-time dependency myself?
I have tried blacklisting 'kernel-module-imx-gpu-viv' setting PNBLACKLIST[kernel-module-imx-gpu-viv] in my local.conf, but that's just a part of a solution. It helps avoid build failures, but the packaging process still fails.
IIUC you problem comes from these lines in img-gpu-viv recipe:
FILES_libgal-mx6 = "${libdir}/libGAL${SOLIBS} ${libdir}/libGAL_egl${SOLIBS}"
FILES_libgal-mx6-dev = "${libdir}/libGAL${SOLIBSDEV} ${includedir}/HAL"
RDEPENDS_libgal-mx6 += "kernel-module-imx-gpu-viv"
INSANE_SKIP_libgal-mx6 += "build-deps"
I would actually qualify this RDEPENDS as a bug, usually kernel module dependencies are specified as RRECOMMENDS because most modules can be compiled into the kernel thus making no separate package at all while still providing the functionality. But that's another issue.
There are several ways to fix this problem, the first general route is to tweak RDEPENDS for the package. It's just a bitbake variable, so you can either assign it some other value or remove some portion of it. In the first case it's going to look somewhat like this:
RDEPENDS_libgal-mx6 = ""
In the second one:
RDEPENDS_libgal-mx6_remove = "kernel-module-imx-gpu-viv"
Obviously, these two options have different implications for your present and future work. In general I would opt for the softer one which is the second, because it has less potential for breakage when you're to update meta-fsl-arm layer, which can change imx-gpu-viv recipe in any kind of way. But when you're overriding some more complex recipe with big lists in variables and you're modifying it heavily (not just removing a thing or two) it might be easier to maintain it with full hard assignment of variables.
Now there is also a question of where to do this variable mangling. The main option is .bbappend in your layer, that's what appends are made for, but you can also do this from your distro configuration (if you're maintaining your own distro it might be easier to have all these tweaks in one place, rather than sprayed into numerous appends) or from your local.conf (which is a nice place to quickly try it out, but probably not something to use in longer term). I usually use .bbappend.
But there is also a completely different approach to this problem, rather than fixing package dependencies you can also fix what some other package provides. If for example you have a kernel configured to have imx-gpu-viv module built right into the main zimage you can do
RPROVIDES_kernel-image += "kernel-module-imx-gpu-viv"
(also in .bbappend, distro configuration or local.conf) and that's it.
In any case your approach to fixing this problem should reflect the difference between your setup and recipe assumptions. If you do have the module, but in a different package, then go for RPROVIDES, if you have some other module providing the same functionality to libgal-mx6 package then fix libgal-mx6 dependencies (and it's better to fix them, meaning not only drop something you don't need, but also add things that are relevant for your setup).
While deploying packages of Matlab code using Matlab 2015 I encountered the problem of gathering all required files from my repository to run a certain file or set of files. Matlab has a method for simplifying this process, matlab.codetools.requiredFilesAndProducts.
However, sometimes some files are missing in the repository (either because I got a package from someone else who was not that careful or because it was not checked in in the repository).
When running the code one would get of course an error:
Undefined function or variable 'XXX'.
However, this may take long to fix (running takes long, you would have to repeat for every missing file). Therefore I thought to use the function above. Unfortunately, it only lists existing files in the output (I tested this). Functions that are called from your code, but that are not present in the current path are omitted by matlab.codetools.requiredFilesAndProducts.
My problem: I would like to get a list of all files that are required by running a certain file but are not present in the current path so that I can find them and add them to my collection.
I know that this must be an iterative process because the missing files could themselves call other missing files and I know that there would be false positives, some of these items could be unknown variables instead, and I know that the missing files would only have a name, no path (of course).
My question: What is the easiest way to find a list of potentially missing files of my code in one go?
Please note that function depfun has been removed in recent versions of Matlab.
In JOGL, there are lots of native jars for different OS x arch combinations. JOGL has several of its own mechanisms to load the right ones if you aren't using java.library.path, and supports a kind of "fat jar" layout.
In a fat jar layout, any native libraries need to be in a subdirectory ./natives/os.and.arch/. However, since the native jars themselves don't have any internal layout, similarly named so/dylib/dll files collide the flat hierarchy in the final jar.
From what I can tell, I don't think I want to de-duplicate with any of the given MergeStrategy because it's only invoked if there is a collision. The layout is mandatory per JOGL's native library loaders - I want to invoke it every time. Is there a mechanism that can allow me to map certain jar -> prefix/with/path in sbt-assembly?
Example
jogl-all-2.1.3-natives-android-armv6.jar is pulled in through a dependency.
$ jar -tf jogl-all-2.1.3-natives-linux-amd64.jar
META-INF/MANIFEST.MF
libjogl_mobile.so
libnewt.so
I'd like this to go here in the final jar:
./natives/
./natives/linux.and.amd64/
./natives/linux.and.amd64/libnewt.so
./natives/linux.and.amd64/libjogl_mobile.so
From what I can tell, I don't think I want to de-duplicate with any of the given MergeStrategy because it's only invoked if there is a collision. The layout is mandatory per JOGL's native library loaders - I want to invoke it every time.
All merge strategies are invoked every time. MergeStrategy.deduplicate, which is the default strategy for most files, just happens to take effect only if there's a collision.
MergeStrategy.rename, applied for README and license files by default for example, will rename the file every time by appending the jar name.
Is there a mechanism that can allow me to map certain jar -> prefix/with/path in sbt-assembly?
There's no strategy out of the box that does exactly that, but you can define a custom strategy similar to MergeStrategy.rename.
Just follow this rule as Xerxes explained here. There is then no longer any risk of collision. The official JogAmp forum is a better place to ask questions about all JogAmp APIs. If you don't follow my advice, GlueGen will be unable to extract and load the correct native libraries. In your case, natives/linux-amd64 is correct whereas natives/linux.and.amd64 isn't.