On dimanche 19 août 2018 18:11:32 CEST Ben Cooksley wrote: > On Sun, Aug 19, 2018 at 10:29 PM David Faure <fa...@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, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
