7878 2015-06-11 09:11:57 +0000 bitbake world -cconfigure -k failed 2015-11-17 10:28:36 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 1.9 x86 Multiple VERIFIED FIXED Medium normal 2.1 1 liezhi.yang liezhi.yang bogdanx.a.voiculescu poky.bs.watcher poky.watcher randy.macleod richard.purdie bogdanx.a.voiculescu --- --- No (bug/feature does not impact docs) oldest_to_newest 51633 0 liezhi.yang 2015-06-11 09:11:57 +0000 NOTE: Preparing RunQueue ERROR: Task do_configure does not exist for target gcc-source-4.9.2. Close matches: do_preconfigure Summary: There was 1 WARNING message shown. Summary: There was 1 ERROR message shown, returning a non-zero exit code. I think that it should go on the build since "-k" is used rather than stop immediately ? 51648 1 richard.purdie 2015-06-11 15:09:43 +0000 Robert, could you explain why you'd like this to work please and what you're trying to do here? The error is going to be hard to fix since bitbake expands "world" to explicitly list all recipe names before passing things off to runqueue to execute. The -k option will not help in cases where explicit targets passed to runqueue fail. 51658 2 liezhi.yang 2015-06-12 01:38:10 +0000 (In reply to comment #1) > Robert, could you explain why you'd like this to work please and what you're > trying to do here? Thanks for the reply, I don't have a strong reason to run bitbake world -k -cconfigure, in my case, I edited autotools.bbclass, and I wanted to make sure the do_configure works well for all the recipes, the "bitbake world" will help in this case, but "bitbake world -cconfigure" can save a lot of time, and I can run "bitbake world" again if the configure works will. The only failed recipe is gcc-source, others work well. > > The error is going to be hard to fix since bitbake expands "world" to > explicitly list all recipe names before passing things off to runqueue to > execute. The -k option will not help in cases where explicit targets passed > to runqueue fail. 53500 3 randy.macleod 2015-08-27 16:53:38 +0000 work-around: EXCLUDE_FROM_WORLD = "1" for gcc-source would unblock you. I'll send a patch with this change for gcc-source-* I think I may have started this when I tried to run: bitbake -c fetch world and that failed as well. The reasons for bring the 'world' to each bitbake stage vary. In my case, I wanted to run a source code indexer over the entire set of software as a tool for fun, err to helping me diagnose problems. In Robert's case, he is re-basing our distro onto an updated oe-core, meta-oe layers and he'd like to identify problems as quickly as possible. Running just configure on all packages in world takes < 1 hr, whereas building all packages takes many hours. In general, is there a good reason that: bitbake -c <stage> world should not be made to work? If it's acceptable, tests should be added to the autobuilder configs. 53608 4 randy.macleod 2015-09-01 18:42:39 +0000 commit 0eda7b4d889b926ab97d60fcbb1c0d12d730f8ea Author: Randy MacLeod <Randy.MacLeod@windriver.com> Date: Thu Aug 27 23:09:47 2015 -0400 gcc-source: exlude from world Exclude all versions of gcc-source from world builds so that: bitbake -c <stage> world will work. gcc-source deletes most bitbake build stages since it is a source-only package. Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com> 56511 5 bogdanx.a.voiculescu 2015-11-17 10:28:36 +0000 no error on fc45deac89ef63ca1c44e763c38ced7dfd72cbe1"