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

[David Faure]

On vendredi 24 août 2018 14:00:12 CEST Ben Cooksley wrote:
> > > 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.

OK. I guess using the install prefix for this made sense when we installed 
before running tests ;-)
Now with the new logic it seems like a bit of a strange location (since the 
stuff isn't installed there), but why not, it makes no difference on Unix
(it's the "future install prefix" now).

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

Right. On Windows the only solution I can think of, is to copy that stuff into 
bin/data in the builddir.

Indeed for a developer trying to work in a custom prefix on Windows, the setup 
isn't ideal. We still need a solution for that in QStandardPaths, but I don't 
know what it would be (env var? config file?). It's been hard to get this 
changed in Qt because any of this would not be "standard", breaking the name 
of the class :-)

AFAICS a developer would have to either install/copy dependencies into 
build/bin/data or to install them into the actual standard paths.

At runtime for deployed applications I think the KDE-windows people are fine 
with everything in bin/data?

> > > 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.

Oh indeed. I remembered wrong.

So /home/jenkins/install-prefix/share has the stuff needed by the current job 
(and only one job at a time can run). OK.

> 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.

I'm curious: why? Why not a "fixed" path like on Unix?

> 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.

Not on Windows, since QStanrdPaths won't find stuff in a random custom prefix 
:-)

KDE-Windows people, any input?

Otherwise, short term, if the CI could use build/bin instead as install prefix 
for the dependencies, it seems to me that it would help.

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