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

[Christopher Larson]

On Thu, May 19, 2016 at 7:19 AM, Alexander Kanevskiy <kad at kad.name> wrote:

> 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.
>

I don't really understand the point you're trying to make here. As far as I
can tell, wic put bmaptool into deploy/tools/ as a convenience for the
user, not for wic itself to use, so it already does what you're saying it
should do.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160519/1ca35b5b/attachment-0002.html>