<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 19, 2016 at 2:50 PM, Alexander Kanevskiy <span dir="ltr"><<a href="mailto:kad@kad.name" target="_blank">kad@kad.name</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Thu, May 19, 2016 at 5:54 PM, Christopher Larson <span dir="ltr"><<a href="mailto:clarson@kergoth.com" target="_blank">clarson@kergoth.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><span class="">On Thu, May 19, 2016 at 7:19 AM, Alexander Kanevskiy <span dir="ltr"><<a href="mailto:kad@kad.name" target="_blank">kad@kad.name</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><span class="">On Wed, May 4, 2016 at 9:55 PM, Christopher Larson <span dir="ltr"><<a href="mailto:clarson@kergoth.com" target="_blank">clarson@kergoth.com</a>></span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br></blockquote></div></span>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.<br><br clear="all"><div>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.</div><span></span></div></div></blockquote><div><br></div></span></span><span class=""><div>We had some private conversation with Richard about deploy/tools, I'll try to summarize results of our discussion here:</div><div><br></div></span></div><span class="">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.</span></div><span class=""><div class="gmail_extra">Those are for usage on another host, where bitbake and content of sysroots are not usually available.</div><div class="gmail_extra">bmaptool is a good example as stand-alone binary that require only python2 and nothing else to run. </div><div class="gmail_extra">Another example is dfu-util-static, which is also, not dependant even on host's libusb even it runs on other host.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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/*</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra">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.</div></span></div></blockquote><div><br></div></span><span class=""><div>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.</div></span></div></div></div></blockquote><div><br></div><div>Yeah, to some extend I'm mixing two topics. Most of above is about putting tools into depoloy/* (as Richard raised concern about that).</div><div><br></div><div><br></div><div>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".</div><div><br></div><div>My initial idea, while creating support for bmap-tools in Ostro, was that image type would depend on bmap-tools-native.</div><div>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.</div><div>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/".</div><div><br></div><div>I also tried in my environment to reproduce scenario as you described in some previous mails in this thread: </div><span class=""><div><br></div><div><span style="font-size:12.8px">> 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.</span><br></div><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">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:</span></div><div><span style="font-size:12.8px"><br></span></div><div><div><span style="font-size:12.8px">$ cat tmp-glibc/work/x86_64-linux/bmap-tools-native/3.2/temp/log.task_order</span></div><div><span style="font-size:12.8px">do_populate_sysroot_setscene (29437): log.do_populate_sysroot_setscene.29437</span></div><div><span style="font-size:12.8px">do_deploy_setscene (29438): log.do_deploy_setscene.29438</span></div><div><span style="font-size:12.8px">do_populate_lic_setscene (29439): log.do_populate_lic_setscene.29439</span></div></div><div><span style="font-size:12.8px">$</span></div></div><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>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*</div></div>-- <br><div class="gmail_signature">Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</div></div>