ECM unittest fails, why?
Friedrich W. H. Kossebau
kossebau at kde.org
Tue Mar 24 06:48:22 GMT 2020
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.
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 :)
Cheers
Friedrich
More information about the Kde-buildsystem
mailing list