hi Richard,

On Wed, Jun 12, 2019 at 2:35 PM Richard Purdie
<richard.pur...@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 {
...
...
}

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'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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

Reply via email to