ECM unittest fails, why?

[Ben Cooksley]

On Tue, Mar 24, 2020 at 7:48 PM Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
>
> Am Montag, 23. März 2020, 20:30:59 CET schrieb Friedrich W. H. Kossebau:
> > Am Sonntag, 22. März 2020, 10:50:39 CET schrieb David Faure:
> > > The CI for ECM has been failing ever since the tests were re-enabled.
> > >
> > > https://build.kde.org/job/Frameworks/view/Platform%20-%20SUSEQt5.12/job/ex
> > > tr a-cmake-modules/job/kf5-qt5%20SUSEQt5.12/103/console shows that
> > > ECMPoQmToolsTest fails with "tr_thread_test.moc: No such file or
> > > directory".
> > >
> > > I have been trying to reproduce this locally, but no such luck.
> >
> > Reason seems to be that on CI the target tr_thread_test is handled before
> > tr_thread_test_2, while for us locally the order is the other way around.
> > And with tr_thread_test_2 the file tr_thread_test.moc is generated first, so
> > present in build dir afterwards, while with tr_thread_test the automoc
> > seems not happening, other than what the code hopes (perhaps some cmake
> > policy change since that code was written?).
> >
> > In general the test setup here seems bogus a bit, as one would expect that
> > the two different test cases (1 & 2) should not share the same url for the
> > generated moc file and have them in respective exclusive include dirs.
> >
> > I might have a closer look later tonight, if no-one else would work on this.
>
> Seems the reason is that the same source file is reused for both targets,
> and the variant without automoc, explicitly calling qt5_generate_moc() on the
> source file, with target tr_thread_test_2, also sees this call (with infile
> being the source file):
>     set_source_files_properties(${infile} PROPERTIES SKIP_AUTOMOC ON)
>
> That property is not bound to any target, but global for the source file. And
> as result enabling automoc with the other target tr_thread_test, by
>     set_target_properties(tr_thread_test PROPERTIES AUTOMOC ON)
> will still keep cmake not doing any automoc for the very source file.
>
> So when tr_thread_test is handled first, the moc file is not yet generated,
> and thus the include of it fails.
> 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...

>
> 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?

>
> Cheers
> Friedrich
>
>

Cheers,
Ben