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

[Ben Cooksley]

On Sun, Aug 19, 2018 at 10:29 PM David Faure <faure at kde.org> wrote:
>
> 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?

The copying is currently grabbing it from the system install provided
by Craft (at C:\Craft\CI\windows-msvc2017_64-cl-debug\bin\data) and
copying it to the local application install directory (at
$WORKSPACE\install-prefix\bin\data). The copy is done for the whole of
bin\data\ so it should grab everything.

My guess is that instead of copying it to the install prefix it needs
to go to $WORKSPACE\build\bin\data\?
(I thought the ECM stuff handled this though)

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

Cheers,
Ben