It would be nice if multibuild.eclass would support nested multibuilds. This would be useful for example in the case, where multiple abis are build inside a multi-build (see sci-libs/fftw-3.3.3-r2::gentoo). multibuild_foreach_variant multilib_foreach_abi some_fct is basically two nested loops for MULTIBUILD_VARIANTS and hence the MULTIBUILD_VARIANT of the outer loop is not available in the inner loop anymore. One solution could to support custom prefix for the loop variables, which fails back to MULTIBUILD_XXX if it is unset. On a side note, if the abi loop would be outside multilib_foreach_abi multibuild_foreach_variant some_fct there would no problem as ${ABI} is always available, but currently this construction won't work at all.
Well, I see two paths from here but I don't think we should take both. So either: a) make use of multibuild.eclass transparent in multilib-build and distutils-r1. Both eclass would restore MULTIBUILD_VARIANT{,S} inside the loop so that they wouldn't interfere with the ebuild. This would fix the issue but still support only one multibuild in an ebuild. Also some people may get confused when multibuild 'disappears' like this. b) support explicit stacking of MULTIBUILD_VARIANT. ${MULTIBUILD_VARIANT} == ${MULTIBUILD_VARIANT[0]} will have the deepest multibuild (like it has one), and ${MULTIBUILD_VARIANT[n]} would go up. In case of fftw, ${MULTIBUILD_VARIANT[1]} (or [-1]) could be used to obtain the eclass variant ([0] would be multilib-build). Immediate issue fixed, though having two nested multibuilds will still require extra effort to set MULTIBUILD_VARIANTS locally.
There was a patch to add that functionality (see url), but it never got applied.
Because nobody bothered to review it.
The patch looks fairly straightforward, and in the absence of any other feedback I suggest just committing it.
Did you test it with your ebuild? In any case, please do and confirm that it works for you ;).
I'm not sure if I'm doing it right or not, but I end up with two identical multilib MULTIBUILD_VARIANTs instead of one multilib and one custom.
Could you attach the patch you are using since I don't want to repeat the process of extracting it from gmane? And also your ebuild :). Then we can figure out what it was all about.
Extracted from mailing list and commited to the gnome overlay for testing in spice-gtk: https://gitweb.gentoo.org/proj/gnome.git/commit/?id=a6623741bbd2f45976d9445d3c28acf26113f8e5
@eva: How is the testing going? Any problems?
