Gitlab CI for Windows

[Ben Cooksley]

On Wed, Jan 5, 2022 at 8:53 AM Christoph Cullmann (cullmann.io) <
christoph at cullmann.io> wrote:

> On 2022-01-04 20:23, Ben Cooksley wrote:
> > On Wed, Jan 5, 2022 at 6:36 AM Christoph Cullmann (cullmann.io [1])
> > <christoph at cullmann.io> wrote:
> >
> >> On 2022-01-04 18:24, Ben Cooksley wrote:
> >>> Hi all,
> >>>
> >>> Next update in this saga appears to be a defect in KDeclarative,
> >> which
> >>> apparently has a hard dependency on KGlobalAccel.
> >>> https://invent.kde.org/sysadmin/ci-management/-/jobs/195039
> >>>
> >>> While this is something that we have previously built on Windows,
> >> from
> >>> my understanding it is essentially a no-op that does nothing so we
> >>> should probably skip building it.
> >>>
> >>> Can someone please take a look into this and advise whether
> >>> KDeclarative can also make it optional?
> >>
> >> Hi,
> >>
> >> I can take a look.
> >
> > If you could, that would be much appreciated.
>
> Nicolas was faster :=)
>
> I would assume master should already build.
>
> I have some additional small patch here
>
>
> https://invent.kde.org/frameworks/kdeclarative/-/commit/7200ad3d518f199ac040afcaf8d3330fd3f79ab7
>
> Btw., it seems the unit tests fail in the classic CI.
> Is it possible that some data/ dir is created in bin/ for Windows?
> This seems to confuse the auto tests where to find their input.
>

Yes, that is to be expected.

On Windows QStandardPaths expects to find resources in the folder data/
immediately relative to the executable.
As our executables are installed into bin/ we therefore have to install
those resources (which on a OSS Unix system would be in $prefix/share/)
into $prefix/bin/data/

The CI Tooling also does some additional tweaking in that department by
copying in the resources from the libraries made available via Craft to
that location as well (otherwise things like shared-mime-database won't be
found)


> Greetings
> Christoph
>

Cheers,
Ben


> >
> >> Greetings
> >> Christoph
> >
> > Cheers,
> > Ben
> >
> >>>
> >>> Thanks,
> >>> Ben
> >>>
> >>> On Tue, Jan 4, 2022 at 7:51 AM Ben Cooksley <bcooksley at kde.org>
> >> wrote:
> >>>
> >>>> On Mon, Jan 3, 2022 at 9:00 AM Ben Cooksley <bcooksley at kde.org>
> >>>> wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> Over the past few days substantial progress has been made in
> >>>>> getting Windows builds running under Gitlab, to the point where
> >>>>> some Frameworks are now successfully compiling.
> >>>>>
> >>>>> Unfortunately we've run into a little issue with breeze-icons as
> >>>>> can be seen at
> >>>>> https://invent.kde.org/sysadmin/ci-management/-/jobs/193039
> >>>>
> >>>> Following investigation and some testing by Harald we've
> >> confirmed
> >>>> that this is a CMake bug - with it being unable to handle
> >> symlinks
> >>>> on Windows correctly.
> >>>> For now I shall workaround the issue by disabling use of symlinks
> >> on
> >>>> Windows in Git (git config --system core.symlinks false) however
> >>>> that is not an ideal long term fix.
> >>>>
> >>>> Do we have any contacts at CMake we can escalate this bug to?
> >>>>
> >>>> As for why this didn't show up earlier - it seems our Windows
> >>>> builders for Jenkins have symlinks disabled (indicating that
> >> either
> >>>> the feature was still too experimental back then or that we did
> >> hit
> >>>> this back then and worked around it then as well)
> >>>>
> >>>>> Any ideas?
> >>>>>
> >>>>> Thanks,
> >>>>> Ben
> >>>>
> >>>> Cheers,
> >>>> Ben
> >>
> >> --
> >> Ignorance is bliss...
> >> https://cullmann.io | https://kate-editor.org
> >
> >
> > Links:
> > ------
> > [1] http://cullmann.io
>
> --
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20220105/fa490b93/attachment-0001.htm>