Summary: | multilib-build.eclass - How many abis are we building for? | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Greg Turner <gmturner007> |
Component: | Eclasses | Assignee: | Multilib team <multilib+disabled> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | Keywords: | PATCH |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://git.overlays.gentoo.org/gitweb/?p=user/gmt.git;a=commitdiff;h=222369f7601576eb846b2606a775a0a0f16261ba | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Greg Turner
2013-10-13 09:46:17 UTC
(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... |