[OE-core] [PATCH v3 4/6] bmap-tools: generate standalone script

Alexander Kanevskiy kad at kad.name
Thu May 19 14:19:27 UTC 2016


On Wed, May 4, 2016 at 9:55 PM, Christopher Larson <clarson at kergoth.com>
wrote:

>
> >
>> > Also, the convention is to add do_deploy before do_build, not before
>> > do_package, otherwise do_deploy's checksum is included int he checksums
>> of
>> > do_package and subsequent tasks, even though its output isn't used by
>> any
>> > subsequent tasks.
>>
>> I also found this a bit unusual to put the tool into deploy/tools.
>> That's why I isolated this change. I think it requires some more
>> testing, but the rest of patchset can be accepted without it.
>
>
> Yeah, putting it there does require some discussion in general.
> Personally, I'm in favor of such a thing, because we don't want to put
> generated convenience tools in the sysroot, since we tell people explicitly
> to not use sysroot contents directly.
>
> Regarding getting it built for the image, I'd suggest adding something
> like IMAGE_TASKDEPENDS to image_type.bbclass, which is basically like
> IMAGE_DEPENDS, but with the task included. I.e. IMAGE_TASKDEPENDS_bmap =
> "bmap-tools-native:do_deploy". Then you wouldn't need the 'before
> do_package', and it'd fix the from-sstate usage.
>

We had some private conversation with Richard about deploy/tools, I'll try
to summarize results of our discussion here:

Thing this, that content under deploy/tools/* supposed to be exported to
"release" directory, and should not be used by any other tool during normal
build/development process.
Those are for usage on another host, where bitbake and content of sysroots
are not usually available.
bmaptool is a good example as stand-alone binary that require only python2
and nothing else to run.
Another example is dfu-util-static, which is also, not dependant even on
host's libusb even it runs on other host.

So, in general, it's for static/standalone binaries that are supposed to be
published as part of "release" of the build, same like deploy/images/*

For any classes, any internals of build process, they never should depend
on content of deploy/* and use *-native tools and binaries out of sysroot.
E.g. wic require bmap-tool, it should be dependant on presence of
bmap-tools-native installed into sysroot, and should be using both modules
and binary out of this sysroot.

This is the way how I'm using it inside Ostro Project:

description in our image type class:
https://github.com/ostroproject/meta-ostro/blob/master/meta-ostro/classes/image-dsk.bbclass#L32
https://github.com/ostroproject/meta-ostro/blob/master/meta-ostro/classes/image-dsk.bbclass#L131

actual  usage of bmaptools modules from sysroot:
https://github.com/ostroproject/meta-ostro/blob/master/meta-ostro/lib/image-dsk.py#L16


-- 
br, Alexander Kanevskiy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160519/c9a3c72f/attachment-0002.html>


More information about the Openembedded-core mailing list