ECM unittest fails, why?

[Friedrich W. H. Kossebau]

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
> 
> <kossebau at 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