On Thu, May 19, 2016 at 7:19 AM, Alexander Kanevskiy <k...@kad.name> wrote:
> On Wed, May 4, 2016 at 9:55 PM, Christopher Larson <clar...@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
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
