KDE CI: Frameworks kservice kf5-qt5 WindowsMSVCQt5.10 - Build # 41 - Still unstable!

[David Faure]

On lundi 13 août 2018 11:08:24 CEST Ben Cooksley wrote:
> Hi David,
> 
> Unfortunately it doesn't look like the fix we put in place on Saturday did
> the trick.
> 
> I have a feeling that QStandardPaths on Windows at least will also consider
> the Qt install prefix in addition to the local to the executable paths when
> searching for mime information. That would explain why the other tests are
> working and why making that change didn't fix it.

Damn, by now I forgot which change we made for that particular test ;-)

The thing is, Qt has its own builtin copy of freedesktop.org.xml so 
QMimeDatabase just works. (So it's not even about the Qt install prefix, Qt 
doesn't install any of this, it's a qrc built into QtCore).
 
> Any ideas why this still fails?

This test is trying to actually find the mimetype xml files on disk in order 
to build the sycoca database (mime->apps mapping). For this, the XML embedded 
into QtCore is completely useless, we need the actual shared-mime-info 
installed somewhere .... where we can find it with QStandardPaths.

How is this usually solved on Windows?

Ah, now I think I remember the change we made: copying the mime stuff to 
data/mime. Well, given the above, it still sounds like the right fix, but I 
wonder what we're actually copying. Is there a data/mime/text/plain.xml
for instance?

Hmm, actually this fails finding the dir in the first place.
QStandardPaths::locateAll(QStandardPaths::GenericDataLocation, "mime", 
QStandardPaths::LocateDirectory);
should really find <executablepath>\data\mime on Windows, there's no doubt 
about that, so I'm wondering if the copying of data\mime happens correctly and 
ends up in the right place?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5