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

[Alexander Kanevskiy]

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.

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