1688 2011-10-19 14:59:40 +0000 [HOB] add multilib support to hob 2014-05-14 16:31:58 +0000 1 1 7 Build System, Metadata & Runtime Hob hob 1.2 x86 Multiple RESOLVED WONTFIX Low enhancement Future 1588 1 msm-oss belen.barros.pena cristian.iorga cristiana.voicu dongxiao.xu jessica.zhang jiajun.xu jjardon msm-oss poky.bs.watcher poky.watcher richard.purdie sgw song.liu --- --- No (bug/feature does not impact docs) oldest_to_newest 16923 0 msm-oss 2011-10-19 14:59:40 +0000 Should be able to add any package as a multilib package as well, perhaps a tab for each type of multilib enabled? 19512 1 shane.wang 2012-03-27 11:56:09 +0000 The feature for Hob was in the latest master. 19871 2 msm-oss 2012-04-04 16:28:43 +0000 What does this mean? [P3][D10] Won't be supported in Hob 19904 3 song.liu 2012-04-04 21:04:00 +0000 Shane, does this mean that this won't be there for 1.2 but will be fixed after 1.2? Song 19906 4 song.liu 2012-04-04 21:05:15 +0000 If it will be done post 1.2, we should keep this bug open and mark its target milestone as 1.3. Thanks! 19977 5 dongxiao.xu 2012-04-06 01:13:57 +0000 The new Hob supports multilib functionality, however it requires users to manually add the following lines into local.conf (Sadly this cannot be configured via Hob now, so I think this is why Shane marks it as post 1.3 feature): require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" 20663 6 song.liu 2012-04-18 17:34:21 +0000 This can be addressed in 1.3. 28677 7 jessica.zhang 2013-01-09 18:21:23 +0000 Belen, Please help on the design work for this. 28803 8 belen.barros.pena 2013-01-14 12:26:54 +0000 Paul has been helping to determine what the requirements are to enable multilib via the Hob interface. This is what came up in our conversation: 1. enabling multilib involves selecting one or more variants. There are 3 of them listed in /poky/meta/conf/multilib.conf (lib32, lib64 and libx32), but these are only for Intel architecture. Do we know how many variants are there overall? 2. enabling multilib also involves specifying a DEFAULTTUNE for the selected variant. The idea would be not to expose this through Hob though (i.e. selecting a variant in Hob also specifies the required DEFAULTTUNE). This means we need to somehow map each multilib variant to its DEFAULTTUNE. 3. enabling a single multilib variant (e.g. lib32) brings in 18 additional base images. As part of this bug, we might need to tackle 2345 then, because multilib really strains our current interface to select base images. 4. according to Paul, the main multilib use case is building the multilib version of specific recipes / packages (you wouldn't build a whole base image with multilib support). This means that the ability to select the multilib variant for specific recipes / packages is important and needs to be well supported. The problem is that multilib variants are named with a prefix ("lib32-"+<recipe name>), which means that the alphabetical sorting by recipe or package name does not list together a recipe / package and their multilib variants, making selection hard (if I want to build multilib for acl, I need to go hunting for lib32-acl far down the recipes table). We need to come up with a way of sorting that will put lib32-acl right below acl in the recipes table. Is there anything else we might be forgetting? 28815 9 msm-oss 2013-01-14 16:56:56 +0000 (In reply to comment #8) > Paul has been helping to determine what the requirements are to enable > multilib via the Hob interface. This is what came up in our conversation: > > 1. enabling multilib involves selecting one or more variants. There are 3 of > them listed in /poky/meta/conf/multilib.conf (lib32, lib64 and libx32), but > these are only for Intel architecture. Do we know how many variants are > there overall? Can can determine these from the environment and you can't assume they are static. They can be named anything. In fact I prefer using the what they refer to instead of the canonical names. (eg. ppce500mc -> lib, ppc64e5500 -> lib64) > 2. enabling multilib also involves specifying a DEFAULTTUNE for the selected > variant. The idea would be not to expose this through Hob though (i.e. > selecting a variant in Hob also specifies the required DEFAULTTUNE). This > means we need to somehow map each multilib variant to its DEFAULTTUNE. Also, you need to come up with a list of compatible TUNEs. E.g. x86_64 is not compatible with ppce500mc. > 3. enabling a single multilib variant (e.g. lib32) brings in 18 additional > base images. As part of this bug, we might need to tackle 2345 then, because > multilib really strains our current interface to select base images. > > 4. according to Paul, the main multilib use case is building the multilib > version of specific recipes / packages (you wouldn't build a whole base > image with multilib support). This means that the ability to select the > multilib variant for specific recipes / packages is important and needs to > be well supported. The problem is that multilib variants are named with a > prefix ("lib32-"+<recipe name>), which means that the alphabetical sorting > by recipe or package name does not list together a recipe / package and > their multilib variants, making selection hard (if I want to build multilib > for acl, I need to go hunting for lib32-acl far down the recipes table). We > need to come up with a way of sorting that will put lib32-acl right below > acl in the recipes table. Maybe you just start with static lists for these in the first pass? x86 and x86_64, ppc and ppc64? -M 28850 10 belen.barros.pena 2013-01-16 10:27:09 +0000 Thanks for the feedback, Matthew. From what I understand, I guess there are 2 main approaches here: 1. Free text We provide 2 text fields in Hob where you can enter any values for the variant and the default tune. Advantage of this approach: it's easy to implement. Problems with this approach: - People might not know what values they are supposed to enter - They might enter an incompatible variant / tune combination This approach defers responsibility for entering valid input to users, with the software providing little help. 2. Static list We provide a list of valid variants, from which users can select one or more. We map those variants to compatible tunes, from which people can select one. Advantages: - we support users with little knowledge - we enforce valid input Disadvantages: we need to specify the variants and their valid tunes somehow. Paul mentioned they could be added to the distro configuration. As Matthew suggests, we could start with a few of them, and add over time. Nothing stops us from combine the 2 options above. Jessica, Cristian, Cristiana: do you have any thoughts on this? Thanks! Belen (In reply to comment #9) > (In reply to comment #8) > > Paul has been helping to determine what the requirements are to enable > > multilib via the Hob interface. This is what came up in our conversation: > > > > 1. enabling multilib involves selecting one or more variants. There are 3 of > > them listed in /poky/meta/conf/multilib.conf (lib32, lib64 and libx32), but > > these are only for Intel architecture. Do we know how many variants are > > there overall? > > Can can determine these from the environment and you can't assume they are > static. They can be named anything. In fact I prefer using the what they > refer to instead of the canonical names. (eg. ppce500mc -> lib, ppc64e5500 > -> lib64) > > > 2. enabling multilib also involves specifying a DEFAULTTUNE for the selected > > variant. The idea would be not to expose this through Hob though (i.e. > > selecting a variant in Hob also specifies the required DEFAULTTUNE). This > > means we need to somehow map each multilib variant to its DEFAULTTUNE. > > Also, you need to come up with a list of compatible TUNEs. E.g. x86_64 is > not compatible with ppce500mc. > > > 3. enabling a single multilib variant (e.g. lib32) brings in 18 additional > > base images. As part of this bug, we might need to tackle 2345 then, because > > multilib really strains our current interface to select base images. > > > > 4. according to Paul, the main multilib use case is building the multilib > > version of specific recipes / packages (you wouldn't build a whole base > > image with multilib support). This means that the ability to select the > > multilib variant for specific recipes / packages is important and needs to > > be well supported. The problem is that multilib variants are named with a > > prefix ("lib32-"+<recipe name>), which means that the alphabetical sorting > > by recipe or package name does not list together a recipe / package and > > their multilib variants, making selection hard (if I want to build multilib > > for acl, I need to go hunting for lib32-acl far down the recipes table). We > > need to come up with a way of sorting that will put lib32-acl right below > > acl in the recipes table. > > Maybe you just start with static lists for these in the first pass? x86 and > x86_64, ppc and ppc64? > > -M 43311 11 belen.barros.pena 2014-05-14 16:31:58 +0000 At this point, work will take place on toaster, not hob, so marking as won't fix.