[bitbake-devel] Half-baked proposal: Introduce @{foo} variable expansion for bitbake

[Peter Seebach]

Observed issues:
1. It can be non-obvious to a user that ${foo} in a shell script is
probably expanded by bitbake, unless foo isn't set, but that
${foo#pattern} is expanded by the shell, and so on.
2. Furthermore, because ${foo#pattern} wants to be expanded by the
shell, we can't easily add functionality similar to some of the shell
expansion rules.
3. For instance, think how useful it would be to have an easy way to
express the equivalent of a shell ${foo:+/$foo} or ${foo:+:$foo}
without an elaborate hunk of Python in a ${@...}.

My suggestion:
Right now, I don't see a single @{ anywhere in oe-core. I propose the
introduction of @{foo} as variable-expansion syntax, with intent that
it would acquire the functionality of POSIX shell expansions, at least
as far as:
	@{foo-bar} => bar if foo is unset, else foo
	@{foo+bar} => bar if foo is set
	@{foo:-bar} => -bar, but "empty or unset"
	@{foo:+bar} => +bar, but "empty or unset"
	@{foo#bar} => foo with a minimal leading bar removed
	@{foo##bar} => foo with a maximal leading bar removed
	@{foo%bar} => like #, but trailing pattern
	@{foo%%bar} => like ##, but trailing pattern

And maybe a couple of others:
	@{foo<bar} => foo, with bar as a prefix if foo is set
	@{foo>bar} => foo, with bar as a suffix if foo is set
	@{foo?bar:baz} => bar if foo is set, baz otherwise.

There is a lot of work right now going into replicating these
functionalities. For instance, consider the prefix BBEXTENDVARIANT,
which might be "lib32". I have a name, ${FOO}. I want to express a
value which is:
	${BBEXTENDVARIANT}-${FOO}
if BBEXTENDVARIANT is set-and-non-empty, or
	${FOO}
otherwise.

No problem! I just write:
PREFIX = "${@['', (d.getVar("BBEXTENDVARIANT", True) or "") +
'-'][(d.getVar("BBEXTENDVARIANT", True) or "") != ""]}"

and then use ${PREFIX}${FOO}.

... wait, that's horrible. What if I could write:
	@{BBEXTENDVARIANT+@{BBEXTENDVARIANT}-}
instead? That's practically legible by comparison. Or, with the new
bonus features,
	@{BBEXTENDVARIANT>-}

Yes, I'm sort of volunteering to try to add this functionality in my
Copious Free Time. My thought is that this would be phased:

1. Add the new syntax.
2. Encourage people to use the new syntax.
3. Gradually start discouraging the old syntax.
4. Eventually replace it completely.

Benefits: Much clearer code, a lot fewer inline Python hacks, less
ambiguity about shell variable expansion, and every time you approve of
one of my crazy ideas, a pony gets a lovely apple, crisp and sweet.

-s
-- 
Listen, get this.  Nobody with a good compiler needs to be justified.