All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: bitbake -b with BBCLASSEXTENDed recipes Was: [RFC} glib-2.0 cleanup
Date: Mon, 1 Mar 2010 16:02:45 +0100	[thread overview]
Message-ID: <20100301150245.GC12022@jama> (raw)
In-Reply-To: <BE689342-3D28-4D8F-A58C-36885368CE0F@vanille-media.de>

On Mon, Mar 01, 2010 at 03:43:12PM +0100, Dr. Michael Lauer wrote:
> > And I want to reiterate the importance of new-style staging and
> > leveraging that for BBCLASSEXTEND.
> 
> Sure. That's certainly a good step, I just think it's not enough.

Is it possible to implement some support for old functionality like
bitbake -c clean -b path.to.recipe.with.BBCLASSEXTEND.bb

Now it fails with error like this:
bitbake@jama ~/build.dev.shr.gta $ bitbake -c clean -b ../dev/recipes/libxml/libxml2_2.7.6.bb
ERROR: Parsing error data_fn virtual:native:/OE/dev/recipes/libxml/libxml2_2.7.6.bb and fn /OE/dev/recipes/libxml/libxml2_2.7.6.bb don't match
Traceback (most recent call last):
  File "/usr/bin/bitbake", line 143, in <module>
    main()
  File "/usr/bin/bitbake", line 140, in main
    cooker.cook()
  File "/usr/lib64/python2.6/site-packages/bb/cooker.py", line 608, in cook
    if not self.buildFile(self.configuration.buildfile):
  File "/usr/lib64/python2.6/site-packages/bb/cooker.py", line 500, in buildFile
    taskdata.add_provider(self.configuration.data, self.status, item)
  File "/usr/lib64/python2.6/site-packages/bb/taskdata.py", line 340, in add_provider
    self.add_provider_internal(cfgData, dataCache, item)
  File "/usr/lib64/python2.6/site-packages/bb/taskdata.py", line 376, in add_provider_internal
    eligible, foundUnique = bb.providers.filterProviders(all_p, item, cfgData, dataCache)
  File "/usr/lib64/python2.6/site-packages/bb/providers.py", line 226, in filterProviders
    eligible = _filterProviders(providers, item, cfgData, dataCache)
  File "/usr/lib64/python2.6/site-packages/bb/providers.py", line 188, in _filterProviders
    sortpkg_pn[pn] = sortPriorities(pn, dataCache, pkg_pn)
  File "/usr/lib64/python2.6/site-packages/bb/providers.py", line 46, in sortPriorities
    priority = dataCache.bbfile_priority[f]
KeyError: 'virtual:native:/OE/dev/recipes/libxml/libxml2_2.7.6.bb'

-b was usefull for quick rebuild of modified recipe (ie to rebuild it in workdir
after updating for new staging or BBCLASSEXTEND to see if everything is "the same")

It's really hard to implement something like prefixing -b path with "virtual:native:"
for native variant and use old behavior (clean non-native version) without virtual: prefix)?
Or just nobody cared yet? In this case I would check what can be done.

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         



  reply	other threads:[~2010-03-01 15:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-28 19:39 [RFC} glib-2.0 cleanup Frans Meulenbroeks
2010-02-28 20:05 ` Koen Kooi
2010-02-28 20:26   ` Frans Meulenbroeks
2010-02-28 21:40     ` Graham Gower
2010-03-01 15:15       ` Denys Dmytriyenko
2010-03-01 15:20         ` Frans Meulenbroeks
2010-03-01 15:25           ` Marcin Juszkiewicz
2010-03-06 19:36   ` Frans Meulenbroeks
2010-02-28 21:35 ` Michael 'Mickey' Lauer
2010-03-01  7:30   ` Frans Meulenbroeks
2010-03-01 14:35   ` Koen Kooi
2010-03-01 14:43     ` Dr. Michael Lauer
2010-03-01 15:02       ` Martin Jansa [this message]
2010-03-15 16:48         ` bitbake -b with BBCLASSEXTENDed recipes Enrico Scholz
2010-03-16  3:23           ` Denys Dmytriyenko
2010-03-17  8:48           ` Martin Jansa
2010-03-17 10:03             ` Enrico Scholz
2010-03-01 22:11   ` [RFC} glib-2.0 cleanup Khem Raj
2010-03-01 22:30     ` Denys Dmytriyenko
2010-03-01 22:34       ` Chris Larson
2010-03-01 22:49         ` Khem Raj
2010-03-01 22:51           ` Chris Larson
2010-03-01 23:04             ` Khem Raj
2010-03-01 23:26               ` Chris Larson

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=20100301150245.GC12022@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.