On Tue, Mar 24, 2020 at 7:48 PM Friedrich W. H. Kossebau <[email protected]> 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
