**** BEGIN LOGGING AT Wed Apr 20 02:59:56 2022 Apr 20 08:17:58 can I build two images with two different DISTRO values out of the same build directory? Apr 20 08:18:23 or is it necessary to have two entirely separate build directories, one for each distro? Apr 20 11:17:29 dv_: that should be fine Apr 20 11:19:59 if for example one recipe checks the DISTRO_FEATURES variable, how is this handled? is the recipe built once per distro? Apr 20 11:20:40 the hash will change and it will rebuild Apr 20 11:21:08 it *will* delete anything from tmp that isn't needed, so if you then expect to use files from both distros that won't work Apr 20 11:21:15 so if I built for distro A, then for distro B, then back for distro A, it will be rebuilt in all cases? Apr 20 11:21:23 the back to A will use sstate Apr 20 11:21:28 ok Apr 20 11:21:57 is there anything I should add to a recipe to let bitbake know that the recipe's behavior differs based on distro_features? Apr 20 11:22:02 or is this figured out automatically? Apr 20 11:22:16 I mean, is the hash updated automatically without any extra recipe metadata? Apr 20 11:29:54 dv_: bitbake will figure it out. However, while it technically works to use the same build directory to build for two different distros, I would recommend to use separate build directories in that case. If nothing else, to avoid churn when switching between the two images. Apr 20 11:41:37 agreed unless the 2 DISTROs are almost identical Apr 20 14:58:40 alright, will do 2 separate builds then. Apr 20 15:00:07 and, is it possible to somehow instruct bitbake to compile a recipe exclusively? for example, if I have a very big component that takes a long time to build, I'd like bitbake to not build anything else in parallel. also, that component then should be built with the number of cores instead of the default parallel_make count. Apr 20 15:00:36 I know how to do the latter - I just add PARALLEL_MAKE_pn- to local.conf. but is the former possible? Apr 20 15:25:59 no Apr 20 15:26:56 would that actually be a net win? have you benchmarked building just that component and then everything else vs all at once? Apr 20 15:27:40 it can be, for example if I modify the packageconfigs of that big package and then build an image again Apr 20 15:27:53 then only that package is rebuilt before the image is generated Apr 20 15:28:11 and in that case, using all available hw cores/threads helps Apr 20 15:28:26 set parallel make explicitly then in that recipe Apr 20 15:28:42 or bump it globally Apr 20 15:28:46 as you've obviously got more headroom Apr 20 15:32:06 rburton: the net win could be that chromium doesn't need to build from swap if you can make sure its do_compile is mutualy exclusive with other tasks in bitbake scheduler (I'm lowering PARALLEL_MAKE just for chromium to avoid that) Apr 20 15:32:35 2G ram per thread isn't enough for C++ used in chromium nowaydays :/ Apr 20 15:33:16 and buying another 4 x 32G kit might cause issues on my motherboard Apr 20 15:36:29 yeah I have an 8-core 16-thread machine, and normally, PARALLEL_MAKE="-j 4" BB_NUM_THREADS=4 is fine Apr 20 15:36:46 but in cases like what I described, I'd prefer PARALLEL_MAKE="-j 16" BB_NUM_THREADS=1 Apr 20 15:37:20 otherwise something like qtbase or chromium builds with -j4 on a machine that has then most of its threads unused, and these then take a loong time to build Apr 20 15:41:32 i'd say -j4 is way too low :) Apr 20 15:43:52 agreed if he has at least 32G ram Apr 20 15:47:56 -j4 with 4 bb threads saturates the CPU Apr 20 16:04:08 does oe-core still deny posts from non subscribed addresses? Apr 20 17:01:47 paulg: iirc an admin gets to moderate Apr 20 17:01:58 at least that's how yocto@ works as i'm a moderator there Apr 20 17:03:38 rburton, it came through, so in the end it doesn't matter. -ETOOMANYLISTS Apr 20 17:03:50 https://lists.openembedded.org/g/openembedded-core/message/164701 Apr 20 17:05:12 now I just have to send the patch to restore i8042 qemu support. ;-) Apr 20 17:08:16 dv_: 4/4 is only going ot saturate a 16 thread cpu if all the jobs are cpu-bound, but that's far from being the case Apr 20 17:17:32 paulg: ! Apr 20 17:17:56 paulg: what do you need that for? you can overrride it in a custom machine, obviously Apr 20 17:18:19 relax, I'm just jerking your chain. ;-P Apr 20 17:19:49 was joking about it on #yocto yesterday Apr 20 17:19:57 [04/19/22:16:32] * paulg sheds a tear and waves bye to PS/2 and i8042 Apr 20 17:20:42 amazing the turd lived this long. Apr 20 17:40:37 yeah Apr 20 17:43:46 raise your hand if you recall the i8042 as a discrete chip in a DIP socket right beside the blue-cladded NiCd right beside the dime sized keyboard plug. Apr 20 17:45:03 think discrete i8042 dried up in the 386dx vintage? Apr 20 17:50:48 unfortunately a lot of those 3 cell NiCd dried up by spitting corrosives onto the motherboards. Apr 20 17:51:10 switch to CR2032 was a win. Apr 20 18:34:28 khem: Have you had time to take a look at https://github.com/kraj/meta-clang/pull/607 and https://github.com/kraj/meta-clang/pull/606 ? Apr 20 18:34:28 I am not sure how to interpret the build failure, if it is something related to my changes... Apr 20 18:35:17 esben: thanks for reminder, not yet, I have been traveling so distracted a bit Apr 20 18:56:47 Ok, thanks. No rush 🙂 **** ENDING LOGGING AT Thu Apr 21 02:59:57 2022