On Feb 21, 2019, at 13:28, Mark Hatle <[email protected]> wrote:
>
>> 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.
That would be an elegant, dependency-aware alternative to this packaging script
for OpenXT, with more than a dozen invocations of bitbake, to build virtual
machines and package them for installer ISO, network bootable images and OTA
update.
https://github.com/OpenXT/openxt/blob/master/do_build.sh
https://github.com/OpenXT/xenclient-oe
Rich
_______________________________________________
Openembedded-architecture mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
