<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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><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 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><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><br><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"><span>><br>
> Also, the convention is to add do_deploy before do_build, not before<br>
> do_package, otherwise do_deploy's checksum is included int he checksums of<br>
> do_package and subsequent tasks, even though its output isn't used by any<br>
> subsequent tasks.<br>
<br>
</span>I also found this a bit unusual to put the tool into deploy/tools.<br>
That's why I isolated this change. I think it requires some more<br>
testing, but the rest of patchset can be accepted without it.</blockquote></div><br></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><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></div>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.</div><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></div></blockquote><div><br></div><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></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>