**** BEGIN LOGGING AT Fri Nov 02 02:59:58 2018 **** BEGIN LOGGING AT Fri Nov 02 04:09:59 2018 Nov 02 11:41:44 I'm puzzled. I get "This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities." insane.bbclass seems to look for "CROSS COMPILE Badness" in config.log, but of those I have none. Nov 02 11:44:30 I'm not puzzled. It looks for another string as well :) Nov 02 11:56:41 Seems to be the include directories that is the problem. 5943:cc1plus: warning: include location "/usr/include" is unsafe for cross-compilation [-Wpoison-system-directories] Nov 02 12:04:52 yeah thats it Nov 02 12:05:06 the cross compile badness string was removed from gcc ages ago, master doesn't look for that anymore Nov 02 14:08:22 JaMa: meta-qt5/rocko got broken Nov 02 14:47:59 RP: is it expected that do_task[recrdeptask] += "do_task" (i.e. same task name on both sides) doesn't work? I don't want to add a do_task_all, and I can't use --runall or --runonly. Nov 02 14:48:25 RP: I traced through runqueue.py, and what happens is the "# Remove recrdeptask circular references so that do_a[recrdeptask] = "do_a do_b" can work" step ends up nuking all the deps Nov 02 14:49:45 do_task has no deps on other tasks, by the way. I just want to recursively run this isolated task. Nov 02 14:54:22 laplante: we go around in circles on this :/ Nov 02 14:55:44 laplante: I think you might want recideptask Nov 02 14:57:11 RP: I have tried that as well, do_task[recideptask] = "do_task" but they still get pruned. Nov 02 14:58:02 do_task[recideptask] = "do_${BB_DEFAULT_TASK}" won't work, since there is no "addtask do_task before do_build" deps. Nov 02 14:58:45 laplante: I suspect recrdeptask should work and be enough and that its gotten broken somehow Nov 02 14:58:59 laplante: there were runqueue changes in Feb which make have done it Nov 02 14:59:45 RP: I already tried with those changes reverted but they didn't change the behavior. Nov 02 15:00:31 laplante: btw, I still want to find time to reply to your question on bitbake-devel, am just not finding time :( Nov 02 15:00:54 RP: of course, sorry to bug you all about it. I know you're busy with new releases. Nov 02 15:01:30 laplante: just wanted to say its something I do care about, no response isn't good though :( Nov 02 15:01:40 RP: no worries :) Nov 02 15:01:54 RP: regarding recrdeptask, I think what's happening is the "self.runtaskentries[tid].depends.difference_update(recursivetasksselfref)" is too overzealous Nov 02 15:03:05 laplante: looking at the code I'd probably agree. I think that code is guarding against cases where two recipes both do do_task[recrdeptask] = "do_task" Nov 02 15:03:27 Well, where N recipes do it Nov 02 15:03:52 RP: right. I tried changing it to "self.runtaskentries[tid].depends.difference_update(tid)", but that lets indirect circular dependencies through Nov 02 15:04:41 laplante: do you really have to call both "do_test" ? Nov 02 15:05:53 laplante: the question is how the code can possibly filter indirect circular dependencies Nov 02 15:08:32 RP: well, not 100% have to, but I'd really like to. The real purpose of the task is this: it's used in both image and non-image recipes. In non-image recipes, I capture some information about the build (SRCREV, branch, etc.) in JSON format. In image recipes, I aggregate those JSON files. Previsously I was manually switchign on and off the aggregation behavior. But then I realized, the aggregation behavior is always useful. Nov 02 15:08:50 RP: And I know about buildhistory and friends, but it didn't fit my purpose Nov 02 15:09:41 RP: not sure about filtering the circular deps :(. Nov 02 15:10:24 laplante: I'm not sure the circular deps issue can be solved generically or deterministically. You have to cut the chain somewhere, but where Nov 02 15:11:13 laplante: two separate tasks, generate and aggregate might work since Nov 02 15:11:38 they'd have separate namespace and it may be a solvable task graph Nov 02 15:17:45 RP: yup, will probably have to do that in the meantime Nov 02 15:22:33 RP: would it make sense to make a distinction between recbdeptask (recursive build tasks) and recrdeptask (recursive runtime tasks)? Say we've got a library recipe (libsoftware.bb) and an application that uses that lib (app.bb), both of which are using my do_task. app:do_task should rightly depend on libsoftware:do_task, but why should libsoftware:do_task also depend on app:do_task? Nov 02 15:22:52 RP: It seems to me if we use the build dependency graph to constrain calculation of the recrdeptask/recbdeptask graph, things would make sense. Nov 02 15:25:20 laplante: we once had such a distinction. It was a total nightmare Nov 02 15:25:38 laplante: it also just moves your problem, doesn't solve it Nov 02 15:30:28 laplante: I guess it would be the same except for the add_runtime_dependencies(taskData[mc].rdepids[taskfn], tasknames, depends, mc) line Nov 02 15:32:07 RP: ah, ok. In that case I'm all out of ideas for now :/. Nov 02 15:32:51 laplante: recdeptask did once exist but it wasn't used by anything and a maintenance problem. The code might handle it better/easier now, not sure Nov 02 15:38:02 RP: might check into that, thanks. I feel like a solution is definitely possible, but I'll be damned if I can think of it on a friday Nov 02 15:41:19 laplante: the trouble is with build deps only, you'd find things in the image which your tools hadn't seen Nov 02 15:41:29 for most people that is bad Nov 02 15:42:49 RP: sorry, can you explain what you mean? Nov 02 15:43:43 laplante: If you make this only process build dependencies and put it in an image recipe, you'll not see many dependencies Nov 02 15:45:19 RP: is that because what the image is really depending on is the do_package_write_* tasks? Nov 02 15:45:45 laplante: its because the image's dependenies are from RDEPENDS = xxx Nov 02 15:47:07 RP: ah, right. Nov 02 15:51:24 RP: so if I were to spend a weekend working on this, is there a particular angle to the problem you'd suggest I explore first? Nov 02 15:52:49 laplante: well, I think the kind of dependency you're asking for may be impossible to implement :/ Nov 02 15:59:31 denix: can you please send a fix? Nov 02 16:08:22 JaMa: "fix" as in revert? :) Nov 02 16:12:51 denix: no, fix as LIC_FILES_CHKSUM update Nov 02 16:13:18 JaMa: yeah, I was kidding :) almost done with the fix Nov 02 16:23:30 JaMa: http://lists.openembedded.org/pipermail/openembedded-devel/2018-November/121289.html Nov 02 16:25:13 RP: oh :/. well I'll keep thinking about it. thx for your time. Nov 02 16:37:42 denix: merged, thanks **** ENDING LOGGING AT Sat Nov 03 02:59:58 2018