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

[David Faure]

On dimanche 19 août 2018 18:11:32 CEST Ben Cooksley wrote:
> 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\?

That sounds right.

While running tests for kservice, the install prefix of kservice shouldn't be 
visible at all....

> (I thought the ECM stuff handled this though)

I'm not sure what you're referring to. Which ECM stuff, handling what?
(certainly there's nothing copying dependencies into build/bin/data....)

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