> -----Original Message-----
> From: [email protected]
> <[email protected]> On Behalf Of
> Joshua Watt
> Sent: den 12 juni 2019 15:56
> To: [email protected]; openembedded-architecture
> <[email protected]>
> Subject: Re: [Openembedded-architecture] Syntax for multiple overrides?
>
> On 6/12/19 8:51 AM, [email protected] 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
The linked suggestion above shows another problem:
| push override "foo"
| DEPENDS += "libbar"
| SRC_URI_append = "file://foo"
| pop override
|
| # The above is syntactically equivalent to:
| # DEPENDS_foo += "libbar"
That may be syntactically equivalent, but typically not want you
want and not what you expect from reading the push/pop section
above. What I would expect to get with the above code more
corresponds to:
DEPENDS_append_foo = " libbar"
but this too is not equivalent as the _append is not evaluated at
the same time as the += operator was. To actually get a correct
equivalent code, you would need it to expand to something like:
DEPENDS-foo_foo = "libbar"
DEPENDS += "${DEPENDS-foo}"
| # SRC_URI_append_foo += "file://foo"
So this raises the question what do you want the override block to
generate, code that is syntactically equivalent or functionally
equivalent? Because if we choose the former, then the users will
probably be even more confused about bitbake's already weird syntax.
> >> 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
//Peter
_______________________________________________
Openembedded-architecture mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
