Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] base: Improve handling of switching virtual/x providers
Date: Fri, 06 Nov 2015 13:40:10 +0000	[thread overview]
Message-ID: <1446817210.15270.172.camel@linuxfoundation.org> (raw)
In-Reply-To: <1446813421.15270.168.camel@linuxfoundation.org>

On Fri, 2015-11-06 at 12:37 +0000, Richard Purdie wrote:
> If you build virtual/kernel, then change PREFERRED_PROVIDER_virtual/kernel from say
> "linux-yocto" to "linux-yocto-dev", you see errors from the sysroot about overlapping
> files. The automatic uninstall logic doesn't trigger since the other recipes is
> still technically parsed/buildable.
> 
> What we can do is look at the value of PREFERRED_PROVIDER_virtual/X and raise SkipRecipe
> (skip parsing) if it provides this thing and its not selected. We skip cases no preferred
> provider is set, or the value is in MULTI_PROVIDER_WHITELIST.We also inform the user
> if they try to build something which conflicts with the configuration:
> 
> $ bitbake linux-yocto-tiny
> ERROR: Nothing PROVIDES 'linux-yocto-tiny'
> ERROR: linux-yocto-tiny was skipped: PREFERRED_PROVIDER_virtual/kernel set to linux-yocto, not linux-yocto-tiny
> 
> [YOCTO #4102]
> 
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> 
> diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> index 44ca781..b8f2aea 100644
> --- a/meta/classes/base.bbclass
> +++ b/meta/classes/base.bbclass
> @@ -204,7 +204,7 @@ def buildcfg_neededvars(d):
>          bb.fatal('The following variable(s) were not set: %s\nPlease set them directly, or choose a MACHINE or DISTRO that sets them.' % ', '.join(pesteruser))
>  
>  addhandler base_eventhandler
> -base_eventhandler[eventmask] = "bb.event.ConfigParsed bb.event.BuildStarted bb.event.RecipePreFinalise bb.runqueue.sceneQueueComplete"
> +base_eventhandler[eventmask] = "bb.event.ConfigParsed bb.event.BuildStarted bb.event.RecipePreFinalise bb.runqueue.sceneQueueComplete bb.event.RecipeParsed"
>  python base_eventhandler() {
>      import bb.runqueue
>  
> @@ -257,6 +257,25 @@ python base_eventhandler() {
>              bb.debug(1, "Executing SceneQueue Completion commands: %s" % "\n".join(cmds))
>              bb.build.exec_func("completion_function", e.data)
>              os.remove(completions)
> +
> +    if isinstance(e, bb.event.RecipeParsed):
> +        #
> +        # If we have multiple providers of virtual/X and a PREFERRED_PROVIDER_virtual/X is set
> +        # skip parsing for all the other providers which will mean they get uninstalled from the
> +        # sysroot since they're now "unreachable". This makes switching virtual/kernel work in 
> +        # particular.
> +        #
> +        pn = d.getVar('PN', True)
> +        source_mirror_fetch = d.getVar('SOURCE_MIRROR_FETCH', False)
> +        if not source_mirror_fetch:
> +            provs = (d.getVar("PROVIDES", True) or "").split()
> +            multiwhitelist = (d.getVar("MULTI_PROVIDER_WHITELIST", True) or "").split()
> +            for p in provs:
> +                if p.startswith("virtual/") and p not in multiwhitelist:
> +                    profprov = d.getVar("PREFERRED_PROVIDER_" + p, True)
> +                    if profprov and pn != profprov:
> +                        bb.warn("PREFERRED_PROVIDER_%s set to %s, not %s" % (p, profprov, pn))

Obviously minus the above line. I'll remove that in any version I add to
-next.

Cheers,

Richard

> +                        raise bb.parse.SkipPackage("PREFERRED_PROVIDER_%s set to %s, not %s" % (p, profprov, pn))
>  }
>  
>  CONFIGURESTAMPFILE = "${WORKDIR}/configure.sstate"
> 
> 




  reply	other threads:[~2015-11-06 13:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-06 12:37 [PATCH] base: Improve handling of switching virtual/x providers Richard Purdie
2015-11-06 13:40 ` Richard Purdie [this message]
2015-12-08 18:58 ` Andre McCurdy
2015-12-08 21:13   ` Burton, Ross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1446817210.15270.172.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox