Summary: | Bash associative arrays from eclasses are not available in ebuilds without declare -g | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Anna Vyalkova <cyber+gentoo> |
Component: | Core - Ebuild Support | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | cyber+gentoo, ionen, zmedico |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Anna Vyalkova
2024-01-21 21:54:56 UTC
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. |