There are various circumstances when we might want to know the number of ABI's we are building for. Indeed, multilib.eclass-based provides just such a facility to its consumers; however, since multilib.eclass is oblivious to ABI USE_EXPAND flags, the analogous service in multilib.eclass does not tell multilib-build.eclass consumers what they need to know. In particular, there are a good number of circumstances where an ebuild might want to know if the number of ABI's it is building for is one, or more than one. Worse, the correct means to figure out the answer is pretty non-obvious and there are several incorrect ways that people might try. Therefore I propose we add this as a feature to multilib-build. See my patch at http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=commitdiff;h=065e468fef7df46e64665689f67e08944ca1cd0c;hp=3df06c5faa9c24cb1736ff5d202ac3248644c323 Reproducible: Always
(In reply to Greg Turner from comment #0) > Therefore I propose we add this as a feature to multilib-build. See my > patch at > http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=commitdiff; > h=065e468fef7df46e64665689f67e08944ca1cd0c; > hp=3df06c5faa9c24cb1736ff5d202ac3248644c323 > > Reproducible: Always Actually that had a spurrious comment and got squashed. Now: http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=commitdiff;h=222369f7601576eb846b2606a775a0a0f16261ba
Please replace 'various circumstances' with real use cases. Please omit the cases when we can use ${#MULTIBUILD_VARIANTS[@]}.
(In reply to Michał Górny from comment #2) > Please replace 'various circumstances' with real use cases. Please omit the > cases when we can use ${#MULTIBUILD_VARIANTS[@]}. I think I see your point, if not, my apologies. If I'm understanding what you're asking: The single use-case I have in my overlay is, I want to warn the user about a limitation of multi-abi support in pkg_setup. Initially the code I wrote for this looked like multilib_enabled_abi_count in the patch: I enumerated the ABI's into an array, counted the array items, compared to one, and warned if it was greater. Then I thought, gee, I wish I didn't have to write that somewhat esoteric-looking code to achieve something so straightforward, it's a breeze in regular multilib, shouldn't it also be so with multilib-build? So that's when I decided that there was a need for such a thing. Or am I reading too much between the lines? Are you asking for a use-case in the in-source doc, or concerned that the proposed enhancement is redundant (or both? :) )
I simply can't think of in-tree use case that couldn't be achieved using ${#MULTIBUILD_VARIANTS[@]}. Then, introducing a function that does this the longer way is redundant and will just confuse ebuild developers.
(In reply to Michał Górny from comment #4) > I simply can't think of in-tree use case that couldn't be achieved using > ${#MULTIBUILD_VARIANTS[@]}. Then, introducing a function that does this the > longer way is redundant and will just confuse ebuild developers. How about, then, if I were to refactor like so?: multilib_enabled_abi_count() { debug-print-function "${FUNCNAME}" "$@" local result if [[ $(declare -p MULTIBUILD_VARIANTS) == 'declare -a'* ]] ; then result=${#MULTIBUILD_VARIANTS[@]} else declare -a abis=( $(multilib_get_enabled_abis) ) result=${#abis[@]} fi (( result < 1 )) && result=1 echo "${result}" } So that, regardless of whether or not any multibuild_for*abi were above us in the call-stack, the optimal/most-correct thing would happen?
(In reply to Greg Turner from comment #5) > (In reply to Michał Górny from comment #4) > > I simply can't think of in-tree use case that couldn't be achieved using > > ${#MULTIBUILD_VARIANTS[@]}. Then, introducing a function that does this the > > longer way is redundant and will just confuse ebuild developers. > > How about, then, if I were to refactor like so?: > > multilib_enabled_abi_count() { > debug-print-function "${FUNCNAME}" "$@" > > local result > if [[ $(declare -p MULTIBUILD_VARIANTS) == 'declare -a'* ]] ; then > result=${#MULTIBUILD_VARIANTS[@]} > else Then the function would work incorrect if 'nearest' multibuild use is for something else.
(In reply to Michał Górny from comment #6) > (In reply to Greg Turner from comment #5) > > (In reply to Michał Górny from comment #4) > > > I simply can't think of in-tree use case that couldn't be achieved using > > > ${#MULTIBUILD_VARIANTS[@]}. Then, introducing a function that does this the > > > longer way is redundant and will just confuse ebuild developers. > > > > How about, then, if I were to refactor like so?: > > > > multilib_enabled_abi_count() { > > debug-print-function "${FUNCNAME}" "$@" > > > > local result > > if [[ $(declare -p MULTIBUILD_VARIANTS) == 'declare -a'* ]] ; then > > result=${#MULTIBUILD_VARIANTS[@]} > > else > > Then the function would work incorrect if 'nearest' multibuild use is for > something else. So would ${#MULTIBUILD_VARIANTS[@]} in its bare form -- bash doesn't do lexical closures -- all functions are global. I was wondering if that was what you were thinking in, i.e., multilib-minimal_abi_src_install. I'm pretty sure attempting to nest multilib-minimal's won't work as intended. (NB: I haven't verified this or even given it careful thought -- but I think it could be made to work, by maintaining an explicitly managed "pseudo-stack" of MULTIBUILD_VARIANT_<number> arrays and then passing around <number> along to the callback functions... but that's hardly a simplification for consumers and requires a whole slew of backward-incompatible API changes.)
(In reply to Greg Turner from comment #7) > (In reply to Michał Górny from comment #6) > > (In reply to Greg Turner from comment #5) > > > (In reply to Michał Górny from comment #4) > > > > I simply can't think of in-tree use case that couldn't be achieved using > > > > ${#MULTIBUILD_VARIANTS[@]}. Then, introducing a function that does this the > > > > longer way is redundant and will just confuse ebuild developers. > > > > > > How about, then, if I were to refactor like so?: > > > > > > multilib_enabled_abi_count() { > > > debug-print-function "${FUNCNAME}" "$@" > > > > > > local result > > > if [[ $(declare -p MULTIBUILD_VARIANTS) == 'declare -a'* ]] ; then > > > result=${#MULTIBUILD_VARIANTS[@]} > > > else > > > > Then the function would work incorrect if 'nearest' multibuild use is for > > something else. > > So would ${#MULTIBUILD_VARIANTS[@]} in its bare form -- bash doesn't do > lexical closures -- all functions are global. I was wondering if that was > what you were thinking in, i.e., multilib-minimal_abi_src_install. I'm > pretty sure attempting to nest multilib-minimal's won't work as intended. > > (NB: I haven't verified this or even given it careful thought -- but I think > it could be made to work, by maintaining an explicitly managed > "pseudo-stack" of MULTIBUILD_VARIANT_<number> arrays and then passing around > <number> along to the callback functions... but that's hardly a > simplification for consumers and requires a whole slew of > backward-incompatible API changes.) OK, my mistake: I guess it works because of the localization of MULTIBUILD_VARIANTS in multilib_for*abi, on the premise that the MULTIBUILD_VARIANTS we need is the one at the top of the stack. Based on that I think I'm starting to see the wisdom of your objection to my API -- it gives them an answer, insofar as they are getting the correct value for some particular top of a potential stack of MULTIBUILD_VARIANTS, but in fact, if this code later gets carelessly copy-pasted into another, deeper layer of MULTIBUILD_VARIANT-based code, it will break. I guess I'm comfortable just counting ABI's in the few places I need, rather than lobbying for this function, based on that...
