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

[Christopher Larson]

On Thu, May 19, 2016 at 2:50 PM, Alexander Kanevskiy <kad at kad.name> wrote:

> On Thu, May 19, 2016 at 5:54 PM, Christopher Larson <clarson at kergoth.com>
> wrote:
>
>> 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:
>>>
>>>>
>>>>> 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.
>>
>
> Yeah, to some extend I'm mixing two topics. Most of above is about putting
> tools into depoloy/* (as Richard raised concern about that).
>
>
> Second topic is about subject "which part of image or wic should depend on
> which task". Both me and Ed are trying to understand exact scenario (or
> even better test case) would trigger issue which lead to idea above of
> putting dependencies like IMAGE_TASKDEPENDS_bmap =
> "bmap-tools-native:do_deploy".
>
> My initial idea,  while creating support for bmap-tools in Ostro, was that
> image type would depend on bmap-tools-native.
> This recipe is also responsible to handle deploy/*. Code or dependencies
> of specific image type don't know anything about deploy part, and IMHO
> should not know.
> In case of support in OE-core, I had impression that Ed implemented it
> same way. However, I didn't check myself part that he did in wic, so not
> sure about part of your comment "wic put bmaptool into deploy/tools/".
>
> I also tried in my environment to reproduce scenario as you described in
> some previous mails in this thread:
>
> > You're right that this is very handy, but we hit a problem when building
> from shared state. This uses do_deploy to deploy bmaptool into
> DEPLOY_DIR_IMAGE, but IMAGE_DEPENDS only depends > on do_populate_sysroot,
> not do_deploy, so an image build from sstate won't write this script out.
>
> but don't see issue with it: executing image build where all objects are
> available in sstate, but bmap-tools-native not present in sysroot leads to
> execution of following tasks:
>
> $ cat tmp-glibc/work/x86_64-linux/bmap-tools-native/3.2/temp/log.task_order
> do_populate_sysroot_setscene (29437):
> log.do_populate_sysroot_setscene.29437
> do_deploy_setscene (29438): log.do_deploy_setscene.29438
> do_populate_lic_setscene (29439): log.do_populate_lic_setscene.29439
> $
>
> if it for some reason not like that in code that Ed did for OE-core, we
> need to look at test scenario, investigate and  fix the issue.
>

For what it's worth, I'm no longer able to reproduce this. I did hit it at
one point, but it seems fine now. *shrug*
-- 
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/17d7a1b2/attachment-0002.html>