[Openembedded-architecture] Syntax for multiple overrides?

[Joshua Watt]

On 6/12/19 7:35 AM, Richard Purdie 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.

An alternative syntax proposal: 
http://lists.openembedded.org/pipermail/openembedded-architecture/2017-May/001411.html

In that one, at least bitbake wouldn't have to deal with more braces :). 
I'm not partial to one or the other really, but the compulsive side of 
me is *really* going to want to indent the variables (which I know would 
break all sorts of bitbake parsing).

>
> 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