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

[Ben Cooksley]

On Fri, Aug 24, 2018 at 11:37 PM David Faure <faure at kde.org> wrote:
>
> On vendredi 24 août 2018 11:21:19 CEST Ben Cooksley wrote:
> > > > 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 am really not the best person to be giving advice on current or future
> solutions for CI on Windows, since I don't know what was done about all this.
>
> Are you referring to what I did in ECM so that the tests and executables
> *created by the current repository* go into build/bin? Sure, that's done by
> ECM. But here we're talking about copying the stuff from the *dependencies*,
> aren't we?

Sorry, that was the ECM code I was referring to previously yes.
I can confirm we're talking about dependencies.

>
> How did this work until now, for everything else than mimetypes?
> PATH surely, for libs and executables. But what about things looked up via
> QStandardPaths, which isn't extensible with env vars on Windows?

For tests, I suspect it simply hasn't worked. Actual applications are
fine once installed of course.

>
> > I guess this is something the CI tooling will need to be handling?
>
> I'm confused, because surely something has been done already, no?
> Any lookup done by lib code has to find the files installed by that lib.
> I know we moved some stuff to qrc files, but afaik not everything.
> [though maybe the missing stuff isn't covered by unittests]

We unpack everything needed into the install prefix yes.
CMake and the rest of the tools are more than happy to use the
resources in there as we can point them in that direction using PATH,
CMAKE_PREFIX_PATH, etc.

Qt of course when it comes to QStandardPaths can't be given that
direction, hence the test failures.

>
> > 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.
>
> Devs don't install each framework into its own install prefix, so their
> situation is actually much easier than the CI situation :-)

Ah, sorry it seems i've not explained what the CI system does here completely.
On Linux and FreeBSD we use the same install prefix for everything -
only populating it with what's needed for each build.

On Windows we follow the same concept, with the difference that the
install prefix in question is always within the Jenkins workspace for
that build.
In the case of a KService build for instance, it will find kdoctools,
ki18n, etc all within C:\CI\workspace\Frameworks kservice kf5-qt5
WindowsMSVCQt5.11/install-prefix/

This should (theoretically at least) be reasonably close to a developers system.

Cheers,
Ben

>
> But I'm not a Windows dev, so I might be missing something.
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>