Minimal ebuild example ====================== EAPI=8 inherit kde.org SLOT=0 src_unpack() { echo "${KDE_ORG_CATEGORIES[@]}" } Minimal bash example ==================== ==> first.sh <== declare -A TEST=( [test]=123 ) ==> second.sh <== inherit() { source first.sh } ==> third.sh <== source second.sh echo "${TEST[@]}"
oops (still doesn't work) ==> third.sh <== source second.sh inherit echo "${TEST[@]}"
But if "first.sh" is sourced in the global scope (not in a function), "123" is printed as expected.
(Disregard the bash example, this "inherit()" function doesn't work for any types of variables)
associative arrays from eclasses are only going to be readable with -g because of how eclasses are handled internally by portage aka with: declare -gA KDE_ORG_CATEGORIES=( ... )
(not a problem when it's only used within global eclass scope, but when called inside phases the contents can be lost because it's treated like a local variable)
(In reply to Ionen Wolkens from comment #5) > (not a problem when it's only used within global eclass scope, but when > called inside phases the contents can be lost because it's treated like a > local variable) BDEPEND="${KDE_ORG_CATEGORIES[@]}" Also doesn't work.
(In reply to Anna Vyalkova from comment #6) > (In reply to Ionen Wolkens from comment #5) > > (not a problem when it's only used within global eclass scope, but when > > called inside phases the contents can be lost because it's treated like a > > local variable) > > BDEPEND="${KDE_ORG_CATEGORIES[@]}" > > Also doesn't work. I said global eclass scope, not ebuild (the variables are local to inherit() or so)
In all, I don't think it's worth trying to change how portage handles inherits over just adding a -g when they're needed.
(In reply to Ionen Wolkens from comment #8) > In all, I don't think it's worth trying to change how portage handles > inherits over just adding a -g when they're needed. Thanks, completely missed this flag >_>
(In reply to Ionen Wolkens from comment #8) > In all, I don't think it's worth trying to change how portage handles > inherits over just adding a -g when they're needed. and fwiw KDE_ORG_CATEGORIES does not need it, only used in eclass scope and is marked @INTERNAL we *could* decide that all associative arrays in global eclass should be -g for consistency though, personally I used it in linux-mod-r1 given these internal variables needed to be accessed in phases
Oops, didn't mean to change state.
