Yes, that is true, but then I will need have a mc-default override set in
local.conf any way, since I need distinguish the build for all
multiconfigs, that makes me think it'd better to have a single
mc-${BB_CURRENT_MC} set in OVERRIDES.

//Ming Liu

2018-06-12 19:49 GMT+02:00 Andre McCurdy <armccurdy@gmail.com>:

> On Tue, Jun 12, 2018 at 4:43 AM, Ming Liu <liu.ming50@gmail.com> wrote:
> > Hi, Andre:
> > The reason for needing this multiconfig to be in OVERRIDES, for me, is
> the
> > scenario that I have one recipe but some variables/tasks in it are
> different
> > for multiconfig, for instance:
> >
> > do_install-mc-default () {}
> >
> > do_install-mc-foo() {}
> >
> > and I do not want split them into several almost same recipes with only
> one
> > task different.
>
> Yes, that's clear. But the question is whether you can make the
> over-rides you need self contained within the multiconfig config file?
>
> e.g. to enable an over-ride when you build with multiconfig foo, add:
>
>   OVERRIDES .= ":mc-foo"
>
> to foo.conf
>
> If it works, then it gives you more flexibility - you can pick your
> own over-ride naming, define multiple over-rides per multiconfig, etc.
>
> > //Ming Liu
> >
> > 2018-06-12 1:15 GMT+02:00 Andre McCurdy <armccurdy@gmail.com>:
> >>
> >> On Mon, Jun 11, 2018 at 4:34 AM,  <liu.ming50@gmail.com> wrote:
> >> > From: Ming Liu <liu.ming50@gmail.com>
> >> >
> >> > This is useful when the users want different variables/tasks when
> using
> >> > multiconfig.
> >>
> >> Isn't the idea of multiconfig to select between configurations which
> >> already fully define all necessary over-rides?
> >>
> >> If a particular multiconfig build needs a custom over-ride then the
> >> multiconfig can append to OVERRIDES (or MACHINEOVERRIDES etc, as
> >> appropriate) directly.
> >>
> >> ie to avoid confusion isn't it good if building with a multiconfig
> >> enabled is always equivalent to building with the contents of the
> >> multiconfig file copied directly in local.conf?
> >>
> >> > Signed-off-by: Ming Liu <liu.ming50@gmail.com>
> >> > ---
> >> >  meta/conf/bitbake.conf | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> >> > index 3b2ef9f..0c803d5 100644
> >> > --- a/meta/conf/bitbake.conf
> >> > +++ b/meta/conf/bitbake.conf
> >> > @@ -731,7 +731,7 @@ DISTRO_NAME ??= "OpenEmbedded"
> >> >  # And finally '<foo>_forcevariable' overrides any standard variable,
> >> > with the highest priority.
> >> >  # This works for functions as well, they are really just variables.
> >> >  #
> >> > -OVERRIDES =
> >> > "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:pn-${PN}:${
> MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:
> forcevariable"
> >> > +OVERRIDES =
> >> > "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:pn-${PN}:${
> MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}${LIBCOVERRIDE}:
> mc-${BB_CURRENT_MC}:forcevariable"
> >> >  LIBCOVERRIDE ?= ""
> >> >  CLASSOVERRIDE ?= "class-target"
> >> >  DISTROOVERRIDES ?= "${@d.getVar('DISTRO') or ''}"
> >> > --
> >> > 2.7.4
> >> >
> >> > --
> >> > _______________________________________________
> >> > Openembedded-core mailing list
> >> > Openembedded-core@lists.openembedded.org
> >> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >
>