On 6/12/19 8:10 AM, Nicolas Dechesne wrote:
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 {
...
...
}
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@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
_______________________________________________
Openembedded-architecture mailing list
Openembedded-architecture@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
