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

Ben Cooksley bcooksley at kde.org
Fri Aug 24 10:21:19 BST 2018


On Fri, Aug 24, 2018 at 7:22 PM David Faure <faure at kde.org> wrote:
>
> 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....)

Hmm Okay. I was under the impression there was code in ECM that helped
setup for tests like this by doing the copying.
I guess this is something the CI tooling will need to be handling?

My only concern about that though is it will make running tests
locally for devs harder as they'll need to know to do this.
Thoughts?

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

Cheers,
Ben


More information about the Kde-windows mailing list