As discussed on IRC with @mgorny : <beber_> take a look to the attachement in bu <beber_> bug <beber_> https://509460.bugs.gentoo.org/attachment.cgi?id=376288 <beber_> it's a bit redundant, don't you think ? <mgorny> is that a problem? your non-redudant solution occupies more space and time than that redundancy <beber_> couldn't the long form of ABI (I mean for ABI=x86, getting abi_x86_32) be available as such as short form ? <mgorny> yes, it's planned <beber_> cool :) <mgorny> you can open a bug just to make sure i won't forget about it <beber_> nice, with a blocker to that very bug ? <mgorny> i think all i need is a good, non-colliding, non-confusing name <mgorny> if you want <beber_> nice <mgorny> but i don't remember if i didn't have another issue with that <mgorny> i recall i wanted to do it earlier but something came along <mgorny> but maybe it's irrelevant now <mgorny> oh, one potential issue is the fallback code <mgorny> i.e. arches that don't do multilib <mgorny> on such arch, there's no matching abi_*_* value <beber_> right <mgorny> but i guess that's a minor problem <mgorny> i'd also have to check how multilib-portage deals with that <mgorny> but i guess users of that are screwed up anyway <mgorny> with the deps Reproducible: Always
Just to be clear, do you prefer getting full 'abi_x86_32' or just 'x86_32'? Since the 'abi_' part would be common to all of them. @team: what do you think about naming it MULTILIB_ABI? Could be a little confusing, though, since we have MULTILIB_ABIS in multilib.eclass already.
(In reply to Michał Górny from comment #1) > Just to be clear, do you prefer getting full 'abi_x86_32' or just 'x86_32'? > Since the 'abi_' part would be common to all of them. abi_x86_32 would be nice and avoid some bash tricks when used to compare current ABI to USE flags
23 May 2014; Michał Górny <mgorny@gentoo.org> multilib-build.eclass: + Export MULTILIB_ABI_FLAG for ebuild/eclass use. Bug #509478.
