3298 2012-10-18 08:12:46 +0000 Add a 'world native' target 2013-05-02 12:17:42 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 1.4 x86 Multiple VERIFIED FIXED Design Low enhancement 1.4 M3 1 liezhi.yang hongxu.jia alexandrux.palalau jason.wessel jessica.zhang liang.li2 mark.hatle meta.mr.watcher meta.watcher richard.purdie sgw zhenfeng.zhao --- --- --- oldest_to_newest 26695 0 liezhi.yang 2012-10-18 08:12:46 +0000 The "bitbake world" will build everything, it would be good if we have a "bitbake native (or something else)" which can build all the native tools, this is useful for testing and collecting the native tools. Maybe we can enhance the "bitbake world" to achieve this, or do it in a recipe. Put it in the "oe-core" product at the moment since I don't have detailed design about it. 26698 1 richard.purdie 2012-10-18 09:00:47 +0000 This already exists and is "bitbake universe". Whilst its expected world will not fail, universe can and will due to it building multiple providers of things. 26702 2 liezhi.yang 2012-10-18 09:38:55 +0000 (In reply to comment #1) > This already exists and is "bitbake universe". Whilst its expected world > will not fail, universe can and will due to it building multiple providers > of things. Hi Richard, Maybe I didn't describe it clearly, I meant that "bitbake native" only built the "native" tools, for what I know is that the "bitbake universe" would build everything, and it failed sometimes. 26735 3 jessica.zhang 2012-10-18 14:42:14 +0000 Can you be more specific what's the reason for creating this native target? Customer requirement, or what so ever? thx 26736 4 jessica.zhang 2012-10-18 14:43:46 +0000 Please see my last comment 26742 5 jason.wessel 2012-10-18 15:10:49 +0000 The idea would be to create a set of "pre-built" native tools which could eventually be used across a number of hosts, so as to not have every host have to rebuild everything that is a "native" package. 26756 6 liezhi.yang 2012-10-19 09:53:59 +0000 (In reply to comment #4) > Please see my last comment Hi Jessica, I think Jason has answered your question, can we set it to "Accepted" ? 26757 7 richard.purdie 2012-10-19 10:11:22 +0000 (In reply to comment #5) > The idea would be to create a set of "pre-built" native tools which could > eventually be used across a number of hosts, so as to not have every host > have to rebuild everything that is a "native" package. I think a "world-native" would not allow enough of the flexibility you'd want in this. I suspect a packagegroup listing the native tools you wanted as part of this set would be more appropriate. My main worry is how you'd implement this "world-native" since the only way I can see it working if you don't use packagegroups is to teach bitbake special knowledge about "native" which is shouldn't really need to know anything about. 26758 8 liezhi.yang 2012-10-19 10:29:13 +0000 (In reply to comment #7) > (In reply to comment #5) > > The idea would be to create a set of "pre-built" native tools which could > > eventually be used across a number of hosts, so as to not have every host > > have to rebuild everything that is a "native" package. > > I think a "world-native" would not allow enough of the flexibility you'd > want in this. I suspect a packagegroup listing the native tools you wanted > as part of this set would be more appropriate. > Sounds great, so how about add such a recipe (use packagegroup) in oe-core ? > My main worry is how you'd implement this "world-native" since the only way > I can see it working if you don't use packagegroups is to teach bitbake > special knowledge about "native" which is shouldn't really need to know > anything about. 27372 9 richard.purdie 2012-11-12 22:40:52 +0000 (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #5) > > > The idea would be to create a set of "pre-built" native tools which could > > > eventually be used across a number of hosts, so as to not have every host > > > have to rebuild everything that is a "native" package. > > > > I think a "world-native" would not allow enough of the flexibility you'd > > want in this. I suspect a packagegroup listing the native tools you wanted > > as part of this set would be more appropriate. > > > > Sounds great, so how about add such a recipe (use packagegroup) in oe-core ? I'm ok with doing that and think its the best approach available although I'm still unsure if it makes a huge amount of sense for the project. 27379 10 liezhi.yang 2012-11-13 02:55:08 +0000 (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > (In reply to comment #5) > > > > The idea would be to create a set of "pre-built" native tools which could > > > > eventually be used across a number of hosts, so as to not have every host > > > > have to rebuild everything that is a "native" package. > > > > > > I think a "world-native" would not allow enough of the flexibility you'd > > > want in this. I suspect a packagegroup listing the native tools you wanted > > > as part of this set would be more appropriate. > > > > > > > Sounds great, so how about add such a recipe (use packagegroup) in oe-core ? > > I'm ok with doing that and think its the best approach available although I will use the packagegroup to do it, and add it in meta/recipes-gnome/packagegroups/ > I'm still unsure if it makes a huge amount of sense for the project. I think that it is useful on the 2 aspects: 1) We can share this set of native recipes' sstate cache among different hosts. 2) We can use this set of native recipes to verify whether we can support a host (maybe "bitbake world" is a better verification way) 28386 11 hongxu.jia 2012-12-20 00:34:49 +0000 Merged into master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=44c9d1ff258c31110a2cdca198e6300d705175e2 28569 12 liang.li2 2013-01-07 03:41:51 +0000 no error when run "bitbake -b /path/to/packagegroup-toolset-native.bb" with git master branch commit "958162e96b4a4f23bca94500b5f20975633dd5c6". 32843 13 alexandrux.palalau 2013-05-02 12:17:42 +0000 This is covered by the following Testopia test case: https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=757