Further thoughts on potential syntax changes

Richard Purdie

I've been quiet but have been thinking a lot about the syntax discussions.
I believe we do need to simplify things, at least so the majority of recipes
have simpler assignment syntax that is understandable to new users. There was
a recent question about whether it was preferred to use += or _append and it
is hard to answer. My worries about setting PACKAGECONFIG with ??=, ?= or =
are also still an open problem too.

One potential approach is we'd just map += and =+ to append/prepend operations 
behind the scenes and all would be good. The trouble is there is a difference
in behaviour. _append and _prepend apply to *any* variable value including an 
override value whilst += and =+ only apply to the "default" value and not any 
override value.

This behaviour is taken advantage of by the metadata. The first example you find 
in a build is quilt-native:

do_configure_prepend () {

do_configure_append () {

do_configure_class-native () {

which wants it's prepend/appends always applied but wants to override the
default value in the native case.

As mentioned on IRC, I've played with the idea of a couple of new override
levels, "defval" and "weakval" where:

A = "X"

would become A_defval within the datastore and then += and =+ can become 
prepends and appends to the defval. Sadly if we do that, we need to be able
to know that do_configure_class-native is an override rather than creating
do_configure_class-native_defval and we don't have a way to know that for
example, "configure" isn't an override to the variable "do" yet class-native

Working backwards, I think the question is what we want this syntax to look
like. How do we say "append this to all variants of a variable" vs. "append 
this only to the default value" or "append this only to the overriden value"?
Can we offer a way to clear a certain subset of appends?

We have an immensely powerful syntax, the question is whether we can find a
way to present it which makes sense to more people...

If we did have clear marking of overrides, that could go some way to establishing
a defval override level, which imports our current syntax into the overrides model
which could then open up possibilities like allowing changing or clearing specific 
overrides explicitly and may allow dropping of the different assignment variants 
(ignoring flags :/).

Not sure quite where I'm going with this but wanted to document it a little and 



Join {openembedded-architecture@lists.openembedded.org to automatically receive all group messages.