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:
bitb...@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:[email protected]
Jansa Martin sip:[email protected]
JaMa
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
