On Thu, May 19, 2016 at 2:50 PM, Alexander Kanevskiy <k...@kad.name> wrote:
> On Thu, May 19, 2016 at 5:54 PM, Christopher Larson <clar...@kergoth.com> > wrote: > >> 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: >>> >>>> >>>>> 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
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
