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

[Ben Cooksley]

On Sun, Aug 26, 2018 at 12:00 AM David Faure <faure at kde.org> wrote:
>
> 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).

Yeah. To a certain extent it does still make sense as we need to
capture the stuff which is installed for later builds.

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

I've now arranged for that to start happening.
Unfortunately it looks like KService is still unhappy, just with
different failure messages :)

>
> 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 :-)

I'd suggest an environment variable named something along the lines of
QT_DATA_PATH.
I know historically we've faced quite a bit of resistance from both
module maintainers as well as Qt Company employees on this whole thing
though.

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

Yes. Installing dependencies into build/bin/data/ isn't really
workable unfortunately as if you're building multiple things they'll
get mixed up with each other so it'll end up being copying in practice
I think.

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

>From my understanding that works perfectly yes.

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

Yep.

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

I set it up like this because on Windows it is extremely foreseeable
that software gets installed to a path which is wildly different
compared to what we build it with.
If we were to use a single fixed path then any code which relies on
this single fixed path would pass fine on the CI system, and then end
up failing on end-users systems which is not ideal.

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

I've put code in place now to copy everything over, which should make
this stuff available to tests for now at least.
Ideally, we would have a solution like XDG_DATA_DIRS for Windows and
macOS (which is the proper solution to this)

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

Cheers,
Ben