**** BEGIN LOGGING AT Fri Sep 04 15:48:53 2020 Sep 04 16:32:31 I have a group of framework recipes that needs to compiled with bunch application recipes. Both framework and application shares a single include file which changes with every application recipe/. Sep 04 16:33:38 So I need to rebuild the framework recipes every time with each of the application recipes. Sep 04 16:35:06 Hadi: in framework recipe: DEPENDS = "application-recipe" Sep 04 16:35:39 application recipe does a DEPEND to framework recipe Sep 04 16:36:24 But app1, app2 app2 has different configuration for the framework recipe Sep 04 16:37:25 So framework recipes needs to be rebuild every time for each of the application recipes Sep 04 16:38:48 We are using the famework recipes a tool that needs to compiled for every application recipes Sep 04 16:40:11 Yocto only build a recipe once. That means the framework recipes are build only once. Sep 04 16:41:35 I am looking for a instance of a group of framework recipes for my application recipe. Hope I am able to explain this Sep 04 16:49:45 Hadi: can you describe the framework recipe in more detail? Sep 04 17:01:14 Our framework recipes and application recipes are all separate git repositories. They all shared a common header file that is "application-specific". The dependency is reversed. Each application has it's own header file that it wants to use compile a set of framework library(reciepes). Eg app1, app2 has header_1.h and header_2.h . App1 wants Sep 04 17:01:15 to build frame1.bb frame2.bb with header_1.h . App2 want to build frame1.bb and frame2.bb with header_2.h Sep 04 17:05:37 In other word, application recipes are trying to use a tool library(framework recipes) that needs to build every time. Thus the complication Sep 04 17:06:19 Does it make sense? Sep 04 17:22:52 Hadi: doesn't sound like an ideal situation :) If you can't somehow break that dependency by rethinking you're design, I guess you'll have to ship one version of the framework per application. Sep 04 17:23:09 err, "your design" Sep 04 17:26:10 JPEW: you mean the codeparser cache? Sep 04 17:29:43 RP: I have sent a v2 for go patch, happy that in v2 I dropped the musl patch along with fix Sep 04 17:33:32 The framework recipes produce static libraries that the application recipe consumes it. If you think about it, gcc tool works on the same principle, all applications can pass in its own set of parameters to the gcc tool . The only difference is, we don't build gcc tool every time. gcc is a binary tool. In other words, I am trying to build gcc Sep 04 17:33:33 tool prior to using it in every application recipe. Sep 04 17:34:34 khem: just queued it, thanks Sep 04 17:35:01 Hadi: if each build of the framework is so tightly coupled with the app, and also linked statically, just build it as part of the application? Sep 04 17:37:43 If one build of the framework is shared with multiple apps, and you want to just build it once, create multiple recipes of framework which builds with a certain header file and the apps that want that version just depend on that Sep 04 17:40:19 That is one option, But we got ~100 applications . It will be hard to maintain multiple instance of framework recipes. I was considering BBclassextend Sep 04 17:42:30 Hadi: BBCLASSEXTEND could work well for that FWIW Sep 04 17:43:18 Hadi: or just fetch the framework and the application in the same SRC_URI together Sep 04 17:43:30 If I could pull in all framework git repos and application repo in a single recipe. That would be ideal. But the problem is I need manage the compile of all framework receipes Sep 04 17:44:03 RP: Thanks. I tried that. Sep 04 17:44:13 RP: Ya Sep 04 17:44:43 JPEW: coreparser is generated per process but we need to combine it all together and save it as one cache Sep 04 17:45:06 RP: Ya, I see thats what the code is doing now :) Sep 04 17:45:12 we can do that "out of band" of the ongoing other bitbake things Sep 04 17:45:14 I need to manage the build of all framework git repositories inside a single application recipe Sep 04 17:45:39 RP: Sep 04 17:46:50 RP: what is FWIW Sep 04 17:47:02 Hadi: For what its worth Sep 04 17:47:32 lol Sep 04 17:47:52 I was searching for yocto class Sep 04 17:47:55 Hadi: I'm afraid I don't understand enough about what you're trying to do. I'd imagine a set of framework and application recipes, all BBCLASSEXTENDing off a common list of things to build could work but I don't really know anything about your use case Sep 04 17:48:23 * RP also needs to head afk, its turned into an insane day :( Sep 04 17:48:43 Thanks RP Sep 04 17:49:28 break the dependency by creating framework-headers recipe or some such Sep 04 17:50:14 I guess header is app specific is it ? Sep 04 17:50:37 I would take a harder look at your SW architecture Sep 04 17:51:06 and perhaps build issue is only showing the symptom of larger problem Sep 04 17:51:37 in the framework recipe i would have BBCLASSEXTEN="app1, app2 app3" . In the application recipe(app1.bb) I would use DEPEDS="frame1-app1" in app2 recipe I would have DEPENDS="frame1-app2" Sep 04 17:52:49 Maybe I understand DEPENDS in the wrong way, but doesn't this mean that I BitBake should first build firmware-imx-8m and then do the do_compile_prepend in this recipe? https://gitlab.com/meta-layers/meta-phyboard-polis-imx8mm-bsp/-/blob/master/recipes-bsp/u-boot/u-boot-phytec-imx_2019.04.bb#L17 Sep 04 17:53:38 What's happening here is that I would like to use some binaries which come form another recipe ;) Sep 04 17:53:56 In my recipe. Sep 04 17:54:45 And it does not quit work. Once I manually build the dependency all is good, but it's not triggered automatically. Sep 04 17:55:50 That's the other recipe this depends on: https://github.com/RobertBerger/meta-freescale/blob/2020-08-28-dunfell/recipes-bsp/firmware-imx/firmware-imx-8m_8.5.bb **** BEGIN LOGGING AT Fri Sep 04 18:42:52 2020 Sep 04 20:02:31 So looking at it again I think I found what was the problems. DEPENDS was not enough. xxx[depends] was needed as well ;) Sep 04 20:58:08 yes in such cases you can set specific task level dependency on another task from different recipe Sep 04 21:01:45 RobertBerger: DEPENDS means the other recipe's files were installed and populated into the recipe sysroot before do_configure is run in this recipe, but only a specific list of directories is allowed into staging/sysroot, see staging.bbclass Sep 04 21:06:01 Hi. Does INCOMPATIBLE_LICENSE apply to build time dependencies as well as runtime dependencies? Sep 04 21:10:06 RP, khem: i know you guys are probably busy with M3, but can you please comment on allarch and -dev packages case that I posted the other day? or should I simply create an entry in bugzilla for that? **** BEGIN LOGGING AT Fri Sep 04 21:47:00 2020 Sep 04 22:25:06 zandrey: I really don't see the issue with allarch -dev packages Sep 04 22:25:32 zandrey: not creating them means adding lots of special case code but things will still depend on them since we can't know if a given dependency is allarch or not Sep 04 22:26:04 I can imagine an allarch recipe which did install dev only stuff like a -config script too Sep 04 22:58:33 anyone seeing random harfbuzz build failures with dunfell? harfbuzz-2.7.2/src/hb-common.cc:625:1: error: no previous declaration for 'void hb_version(unsigned int*, unsigned int*, unsigned int*)' Sep 04 22:59:48 JaMa: we've started seeing them in master :/ Sep 04 23:00:13 JaMa: 14038 14036 Sep 04 23:00:33 bugs #14028 and #14036 Sep 04 23:02:13 ah Ross is on it already it seems https://github.com/harfbuzz/harfbuzz/pull/2668 Sep 04 23:04:15 and my failed build I was just looking at was also based on master, not dunfell, will check if dunfell is also affected Sep 04 23:07:33 JaMa: cool, I know rburton said he'd take a look Sep 04 23:25:17 Dear all, I am new to Yocto - I need to build a custom Image for RaspberryPi to fast boot into a QT application. Kindly suggest the right step - I was trying to learn yocto for past few weeks, but quite overwhelming. Please guide Sep 04 23:27:44 SHould i start with OpenEmbedded or with Yocto? Sep 04 23:29:40 Sara: OE is the build environment used by the Yocto Project so its all related Sep 04 23:30:12 Sara: personally I'd try a poky checkout with the addition of the meta-raspberrypi layer, see if you can get basic images booting on your pi Sep 04 23:30:28 once you have the basics, then start on the QT application Sep 04 23:31:19 RP thanks for the note, so poky is the sample project that can be used to build the image Sep 04 23:31:28 RP thanks for the note, so poky is the sample project that can be used to build the image ? Sep 04 23:32:49 Which book do you recommend or link thats meant for Beginners like me (im good at linux but couldnt get hold of yocto last few days) Sep 04 23:33:48 I have been trying to get this working, but this has been failing many times (last 7 times ) Sep 04 23:38:22 Sara: did you try the Quick build document? Sep 04 23:39:05 Sara: the best way forward is probably to try and build up to what you need in stages - get a basic qemu build working ok, then get an image for the raspberrypi, then add QT Sep 04 23:39:36 Sara: https://www.yoctoproject.org/docs/3.1.2/brief-yoctoprojectqs/brief-yoctoprojectqs.html **** BEGIN LOGGING AT Sat Sep 05 01:45:25 2020 **** BEGIN LOGGING AT Sat Sep 05 02:33:42 2020 **** ENDING LOGGING AT Sat Sep 05 02:59:57 2020