[Openembedded-architecture] Syntax for multiple overrides?

[Joshua Watt]

On 6/12/19 8:51 AM, richard.purdie at linuxfoundation.org wrote:
> On Wed, 2019-06-12 at 08:44 -0500, Joshua Watt wrote:
>> 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
>> :).
> The braces bit is actually easier for the parser!

Ah, fair enough

>
>> 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 wanted to indent it too. The parser could probably be taught about it
> relatively easily, its just regexs. I'm not sure that is a good idea
> though.
>
> In the link, Patrick makes a good point, we can't handle all syntax
> within the braces as some don't have overrides conditionals (like
> addtask).

Ya. I suspect you'd want to make anything other than variable 
assignments in a block syntax errors (at least until a sane mechanism is 
determined to handle them).


>
> Cheers,
>
> Richard
>