| Summary: | Add a 'world native' target | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Robert Yang <liezhi.yang> |
| Component: | core | Assignee: | Hongxu Jia <hongxu.jia> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Low | CC: | alexandrux.palalau, jason.wessel, jessica.zhang, liang.li2, mark.hatle, meta.mr.watcher, meta.watcher, richard.purdie, sgw, zhenfeng.zhao |
| Version: | 1.4 | ||
| Target Milestone: | 1.4 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | Design | ||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Robert Yang
2012-10-18 08:12:46 UTC
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. (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. Can you be more specific what's the reason for creating this native target? Customer requirement, or what so ever? thx Please see my last comment 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. (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" ? (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. (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. (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. (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) Merged into master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=44c9d1ff258c31110a2cdca198e6300d705175e2 no error when run "bitbake -b /path/to/packagegroup-toolset-native.bb" with git master branch commit "958162e96b4a4f23bca94500b5f20975633dd5c6". This is covered by the following Testopia test case: https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=757 |