[OE-core] [PATCH V2] bitbake.conf: add BB_CURRENT_MC to OVERRIDES

[Andre McCurdy]

On Tue, Jun 12, 2018 at 4:43 AM, Ming Liu <liu.ming50 at 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 at gmail.com>:
>>
>> On Mon, Jun 11, 2018 at 4:34 AM,  <liu.ming50 at gmail.com> wrote:
>> > From: Ming Liu <liu.ming50 at 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 at 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 at lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>