On 2/21/19 9:44 AM, Burton, Ross wrote: > So I'd like to use multiconfig for a fairly typical host/container use > case. I've a class which can be used to build packages from images in > a fairly simple manner, essential just taking files from DEPLOY_DIR > when creating a package: > > core-image-minimal-package.bb: > do_install[depends] += "core-image-minimal:do_image_complete > virtual/kernel:do_deploy" > do_install () { > install -d ${D}/var/lib/machines/ > install ${DEPLOY_DIR_IMAGE}/core-image-minimal-${MACHINE}.ext4 > ${D}/var/lib/machines/core-image-minimal.ext4 > install ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE} > ${D}/var/lib/machines/${IMAGE_NAME}.${KERNEL_IMAGETYPE} > } > > This part works fine, but the problem is straddling multiconfig boundaries... > > I can't just add "core-image-minimal-package" to IMAGE_INSTALL because > it will build that for the current configuration. I can't just add > "multiconfig:uos:core-image-minimal-package" because that will look > for a recipe with that name. I've a rather ugly hack to call opkg > directly in a post-rootfs hook which sort of works. Linking in bits > of the other configuration's deploy directory in a pre-rootfs hook and > extending IMAGE_INSTALL there almost works, apart from the rootfs code > then looks at the task dependencies to generate a pruned deploy dir, > which is missing the pieces I linked in. > > I suspect this is now breaking new ground: the multiconfiguration > support lets you do builds but so far the artefact sharing hasn't > really been explored. Has anyone dug further into this?
I don't think anyone has. But as we continue moving toward containers/micro services environments -- this exactly type of thing is going to be more and more needed. One 'build', with various configurations that end up constructing a single device image with a container runtime (booting OS), and a number of container micro services should be able to be created with a single call to bitbake and (a potentially complex) config. I think the first question is, can one multiconfig require a dependency out of another yet? I thought this was still unimplemented. Once this can be done, then it should be much easier to have a 'configuration' whose job it is to assemble the various components while waiting for everything to finish being built. --Mark > Ross > _______________________________________________ > Openembedded-architecture mailing list > openembedded-architect...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core