Am Dienstag, 24. März 2020, 08:37:56 CET schrieb Ben Cooksley: > On Tue, Mar 24, 2020 at 7:48 PM Friedrich W. H. Kossebau > > <kosse...@kde.org> wrote: > > Why CI does this order, but not locally for us, no clue so far. > > Could this ordering be a race condition by any chance? > > Two of the three nodes that perform the builds on the CI system are > 3rd generation Ryzen 7 systems (Octa Cores) with NVMe storage, so > there is a possibility this is the case...
There is only one thread/job queue here when make is run if I saw correctly. So no race here I think. It might be rather something which determines the order of otherwise same-level targets handled, something like unsorted hash table layout, random number generation seed, something of that kind, > > No idea right now how to properly fix this (possibly need to have > > different > > source files then, perhaps a symlink), would look again in the evening. > > So feel invited to beat me on a proper solution :) > > Could we add a dependency between the targets to force the correct > ordering be followed? Those two targets should be independent and not have effects on each other, from what I had understood the design of the tests so far. So CI behaviour actually uncovers a flaw of the current cmakelists.txt code (generated moc file visible to build of other target, target specific code with side effects to other targets). The question about order of handling is more of general curiosity, to have full understanding of what we see. Cheers Friedrich