[bitbake-devel] [OE-core] Two recipes providing the same .so... How it should not be done :)

[Richard Purdie]

On Fri, 2019-03-01 at 12:28 +0100, Ricardo Ribalda Delgado wrote:
> Hello
> 
> I have a build system that supports some aarch64 machines. For most
> of
> the them, the only difference is the kernel configuration, kernel
> version.
> 
> I am using multiconfig on my build server and the build goes really
> fast thanks to all the shared binaries/artifacts.
> 
> But I have a problem adding a new machine. This machine is also
> aarch64, with a special kernel (nothing new here), but in this case
> the vendor provides a binary .so for libgl that is required to get
> hardware acceleation.
> 
> I could .bbappend mesa and on the installation part replace libgl
> with
> the new .so. But then everything that depends on mesa needs to be
> rebuilt for that machine and I could not use multiconfig.
> 
> Instead I have created a new recipe: mesa-gl-replace.bb that has the
> file. This breakes completely the design of OE, but works.
> 
> Some snipsets of the "magic" to make it work:
> 
> #Force that the version is allways higher than the one from mesa:
> PE = "5"
> 
> #Rprovide the same as mesa
> RPROVIDES_libgl-mesa += "libgl"
> 
> #Do not overwrite pkgdata of mesa
> PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> rm_pkgdata_runtime() {
> rm -rf ${WORKDIR}/pkgdata/runtime/*
> rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> }
> 
> #Keep this on machine
> PACKAGE_ARCH = "${MACHINE_ARCH}"
> 
> #Make sure we are not saved as providers for libgl
> PRIVATE_LIBS = "libGL.so.1"
> 
> #Avoid sanity checks
> read_subpackage_metadata () {
> }
> 
> 
> If your eyes have not fallen as this point, this means you have a lot
> of tolerance for crappy code, congrats :)
> 
> Now the question. Is there a better way to do this?

I'd probably let mesa build as normal but then add a recipe which
RRPROVIDES, RREPLACES and RCONFLICTS with the specific mesa package you
want to replace. It would create and equivalent package with the right
contents and make it machine specific.

There should be more variables like PRIVATE_LIBS which stop you having
to use the more horrible hacks (INSANE_SKIP_*?).

You might then only have the issue of ensuring this machine specific
package gets installed into the images which need GL (or just install
it in all images for that machine).

Cheers,

Richard