[Openembedded-architecture] Syntax for multiple overrides?

[Joshua Watt]

On 6/12/19 8:10 AM, Nicolas Dechesne wrote:
> hi Richard,
>
> On Wed, Jun 12, 2019 at 2:35 PM Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
>> I'm not 100% sure whether I like this idea or not but wanted to share
>> it and see what others think.
>>
>> We're looking at a recipe which would do:
>>
>> BBCLASSEXTEND = "devupstream:target"
>> LIC_FILES_CHKSUM_class-devupstream = "file://LICENSE;md5=3f882d431dc0f32f1f44c0707aa41128"
>> DEFAULT_PREFERENCE_class-devupstream = "-1"
>> SRC_URI_class-devupstream = "git://git.lttng.org/lttng-modules;branch=master \
>>             file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch \
>>             file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
>>             "
>> SRCREV_class-devupstream = "${AUTOREV}"
>> PV_class-devupstream = "2.11.0-rc+git${SRCPV}"
>> S_class-devupstream = "${WORKDIR}/git"
>>
>> which is a bit ugly. I wondered whether we'd want to support some kind
>> of collective override syntax, e.g.:
>>
>> BBCLASSEXTEND = "devupstream:target"
>> override class-devupstream {
>> LIC_FILES_CHKSUM = "file://LICENSE;md5=3f882d431dc0f32f1f44c0707aa41128"
>> DEFAULT_PREFERENCE = "-1"
>> SRC_URI = "git://git.lttng.org/lttng-modules;branch=master \
>>             file://Makefile-Do-not-fail-if-CONFIG_TRACEPOINTS-is-not-en.patch \
>>             file://BUILD_RUNTIME_BUG_ON-vs-gcc7.patch \
>>             "
>> SRCREV = "${AUTOREV}"
>> PV = "2.11.0-rc+git${SRCPV}"
>> S = "${WORKDIR}/git"
>> }
>>
>> It would be a pain to implement in bitbake but should be possible, it
>> would literally just append _<OVERRIDE> to the variable names when
>> storing them.
> I have no idea about what it means in term of implementation.. but as
> a user of this feature, i think it might be interesting to be able to
> specific more than one override, e.g.
>
> override qemuarm, qemux86 {
> ...
> ...
> }


That's a little harder because it implies "looping" in the recipe, which 
isn't really a concept that bitbake has done before (to my knowledge). 
How often are you setting the overrides to the same thing that this 
would be useful?


>
> I think this is a pattern used in BSP layer especially when we support
> large families of SoC for example. What it would do is exactly what
> you said, but it would do it for each comma separated override. Or if
> you have a layer that creates multiple (similar) distro, e.g.
>
> override poky, poky-tiny {
> ...
> ...
> }
>
> Also, how about other operators, such as _append or _prepend, would
> they be permitted inside the override statement?

I think you have to choose the principal of least surprise so that 
people can still sanely reason about the code; an override block should 
just be syntactic sugar for adding _OVERRIDE to every variable. As such:


override bar {

FOO_append = "blah"

}


is equivalent to:


FOO_append_bar = "blah"


Depending on how "dumb" you want the implementation, we would also need 
to figure out if this is allowed:

override append {

BAR = "baz"

}



>
>> I've been toying with ideas around making a syntax around conditional
>> blocks, the trouble is such things would imply immediate expansion
>> which wouldn't work in many cases.
>>
>> Just thinking out loud really...
>>
>> Cheers,
>>
>> Richard
>>
>> _______________________________________________
>> Openembedded-architecture mailing list
>> Openembedded-architecture at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture