#yocto #zeus Best practices for packaging third party recipe tool output in another recipe on the building host #yocto #zeus


VINCI Maxime
 

Hi, I am quite new to Yocto/BitBake and I have a bit of a headache trying to figure out the best way to make use of a native tool in the following context:

I have one recipe that fetch and build third party libs and binaries, let's call it X.
I have another recipe that also fetch and build third party libs and binaries, those depending on X's libs, let's call it Y.
Y needs to run post installation scripts to generate some config files.
Those scripts are calling some of X's binaries to generate those files, therefore I added a dependency on X-native to be able to run those scripts on the building machine.
At the moment, I include those scripts in do_install[postfuncs] of Y-native recipe while adding it as dependency in Y recipe, as I wish those to files to be part of Y package.

Assuming what I am doing until there is alright (correct me if not), here comes my issue:
The way X is configured/compiled involves specifying the path where it will write any file it generates/manage (currently based on the 'datadir' prefix).
This implies that building X-native will also prefix this path with STAGING_DIR_NATIVE in X recipe context.
So, after using X-native binaries from within Y-native recipe I end up generating files in the wrong STAGING_DIR_NATIVE (ie. X recipe context), being unable to easily retrieve those as it's outside of Y recipe context.

Am I missing something here ?
I read about pkg_postinst and deferring them after sysroot creation, but this is not what I need if I wish to package to config files, right ?
If there are no other solution, I may resort not to package them and use this to generate them at image/sdk creation, but this does not seems clean to me.

Also, I wish not to patch X sources to enable some sort of runtime output path configuration.

Join yocto@lists.yoctoproject.org to automatically receive all group messages.