purpose unittests on Windows

Ben Cooksley bcooksley at kde.org
Sun Aug 19 12:55:49 BST 2018 

On Sun, 19 Aug 2018, 12:19 David Faure, <faure at kde.org> wrote:

> On lundi 13 août 2018 11:06:12 CEST Ben Cooksley wrote:
> > On Mon, Aug 13, 2018 at 1:16 AM David Faure <faure at kde.org> wrote:
> > > On samedi 11 août 2018 07:02:18 CEST Ben Cooksley wrote:
> > > > On Fri, Aug 10, 2018 at 7:28 PM David Faure <faure at kde.org> wrote:
> > > > > Any idea why purpose can't find the KIO http and file protocols --
> on
> > > > > Windows?
> > > > >
> > > > >
> https://build.kde.org/view/Frameworks/job/Frameworks%20purpose%20kf5-q
> > > > > t5%2
> > > > >
> 0WindowsMSVCQt5.10/76/testReport/junit/(root)/TestSuite/alternativesmo
> > > > > delt
> > > > > est/
> > > > >
> > > > > That's very odd, because the dependency from purpose on kio is
> there
> > > > > in
> > > > > kde-build-metadata (it wouldn't build otherwise), and using
> kio_file
> > > > > from
> > > > > other frameworks surely works (e.g. in KParts).
> > > > >
> > > > > The lookup for protocols looks for "kf5/kio" under all Qt plugin
> > > > > directories, i.e. $QT_PLUGIN_PATH.
> > > > >
> > > > > The CI log says
> > > > > QT_PLUGIN_PATH            = 'C:\CI\workspace\Frameworks purpose
> > > > > kf5-qt5
> > > > >
> WindowsMSVCQt5.10\install-prefix\lib\plugins;C:\Craft\CI\windows-msvc2
> > > > > 017
> > > > > _64-cl-debug\lib\qca-qt5'
> > > > >
> > > > > => is there a kf5\kio subdir in C:\CI\workspace\Frameworks purpose
> > > > > kf5-qt5
> > > > > WindowsMSVCQt5.10\install-prefix\lib\plugins ?
> > > >
> > > > I've checked and the following seem to be present in that directory,
> > > > which looks correct to me:
> > > >
> > > > Mode                LastWriteTime         Length Name
> > > > ----                -------------         ------ ----
> > > > -a----        8/10/2018   8:39 PM         274944 file.dll
> > > > -a----        8/10/2018   8:40 PM         352256 ftp.dll
> > > > -a----        8/10/2018   8:40 PM         185856 ghelp.dll
> > > > -a----        8/10/2018   8:39 PM         185856 help.dll
> > > > -a----        8/10/2018   8:45 PM         946688 http.dll
> > > > -a----        8/10/2018   8:40 PM         189440 remote.dll
> > > > -a----        8/10/2018   8:40 PM         122880 trash.dll
> > > >
> > > > Is there any debug output we can enable to see how it is searching
> for
> > > > the plugins?
> > >
> > > I have now added debug output to kcoreaddons and kio, and the result
> is:
> > >     Checking for plugins in ("C:/CI/workspace/Frameworks purpose
> kf5-qt5
> > >     WindowsMSVCQt5.10/build/bin/kf5/kio",
> > >     "C:/Craft/CI/windows-msvc2017_64-cl-debug/plugins/kf5/kio")>
> > > This list doesn't include the above directory,
> C:\CI\workspace\Frameworks
> > > purpose kf5-qt5 WindowsMSVCQt5.10\install-prefix\lib\plugins.
> > >
> > > Yet, ECMAddTests.cmake adds to QT_PLUGIN_PATH, it doesn't overwrite
> it...
> > > I wonder if set(PATHSEP "\\;") is correct though (why double
> backslash?)
> > > QCoreApplication::libraryPaths reads that env var and splits it using
> > > QDir::listSeparator() which is ';' on Windows. Kevin, any reason for
> the
> > > backslash?
> > > Do you see any other reason for this to fail, otherwise?
> >
> > Hi all,
> >
> > I've done some investigation work on this on the CI system this
> > morning and it seems that it isn't even necessary to set
> > QT_PLUGIN_PATH within ECMAddTests (at least on Windows anyway)
>
> I'm confused. Do you mean that *NOT* setting QT_PLUGIN_PATH actually fixes
> the
> finding of kio_file, while setting that env var (as in the CI) breaks
> finding
> it?
> I can't make sense of that, because QCoreApplication::libraryPaths only
> *adds*
> the contents of QT_PLUGIN_PATH into the list of dirs, it doesn't replace
> or
> remove anything...
>


Sorry - not setting QT_PLUGIN_PATH in the CMake code makes it work.

The CI Tooling sets it when it runs so leaving that undisturbed seems to
make it happy.


> > QDEBUG : AlternativesModelTest::bigBufferTest() org.kde.kcoreaddons:
> > Checking for plugins in ("C:/CI/workspace/Frameworks purpose kf5-qt5
> > WindowsMSVCQt5.10/install-prefix/lib/plugins/kf5/kio",
> > "C:/Craft/CI/windows-msvc2017_64-cl-debug/lib/qca-qt5/kf5/kio",
> > "C:/Craft/CI/windows-msvc2017_64-cl-debug/plugins/kf5/kio",
> > "C:/CI/workspace/Frameworks purpose kf5-qt5
> > WindowsMSVCQt5.10/build/bin/kf5/kio")
>
> That's definitely more search paths than what CI currently shows:
>
> Checking for plugins in ("C:/CI/workspace/Frameworks purpose kf5-qt5
> WindowsMSVCQt5.10/build/bin/kf5/kio", "C:/Craft/CI/windows-msvc2017_64-cl-
> debug/plugins/kf5/kio")
>

Yep. That is the additional ones the CI sets.


> > QDEBUG : AlternativesModelTest::bigBufferTest() kf5.kio.core:
> > "C:/CI/workspace/Frameworks purpose kf5-qt5
> > WindowsMSVCQt5.10/install-prefix/lib/plugins/kf5/kio/file.dll"
> > supports protocols ("file")
>
> That's success indeed.
>
> > Unfortunately doing this doesn't fix the test as it's unable to find
> > kioslave.exe, even though it exists in $workspace/install-prefix/bin/
> > so not sure what's happening there:
> > " Can not find 'kioslave' executable at 'C:/CI/workspace/Frameworks
> purpose
> > kf5-qt5 WindowsMSVCQt5.10/build/bin,
> > C:/Craft/CI/windows-msvc2017_64-cl-debug/bin,
> > C:/CI/workspace/Frameworks kio kf5-qt5
> > WindowsMSVCQt5.10/install-prefix/bin'"
>
> According to the last entry in this path, it's looking into the install
> prefix
> for *KIO*, which is indeed where I would expect kioslave.exe to be.
> But you're saying below that somehow kioslave.exe ends up in the install
> prefix for *purpose* instead?
>

Yeah. Each of those workspaces is throw away and is erased at the end of
each run of a job.

In the prepare-dependencies.py script we unpack all the dependencies into
$workspace/install-prefix, then set PATH, etc accordingly to ensure
everything is found.

This test will be working on Linux and FreeBSD because we use
$home/install-prefix there due to Wayland framework hardcoding limitations.

We could potentially do something similar on Windows, however my concern
there would be code that only relies on hardcoded paths would pass on CI
while then failing in production (as our hardcoded install prefix will
never match where a user will install our software)



> > Directory of C:\CI\workspace\Frameworks purpose kf5-qt5
> > WindowsMSVCQt5.10\install-prefix\bin
> > 08/12/2018  06:21 AM            62,464 kioslave.exe
>
> That's the purpose install prefix. How did kioslave.exe get there?
>
> Seems like the wrong place --- it's logical that the purpose unittest are
> not
> going to depend on anything in the purpose install prefix, we're trying to
> run
> tests with the framework being uninstalled.
>
> The issue is likely that kioslave is installed into libexec and not bin.
>

Yeah, it will work for all other executables as they're found in PATH.


> Was there some manual copying done long ago to fix that, but at the time
> copying into the install prefix was enough, while nowadays that can't work
> (now that the install prefix isn't supposed to exist yet)?
>

A long time ago workspaces weren't erased at the end of jobs on the CI
(back when the builders weren't SSD based) which would have let this test
pass most of the time (by accident).

Cheers,
Ben


> Copying from kio's libexec to kio's bin should fix that.
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180819/c0e243bd/attachment-0001.html>

More information about the Kde-frameworks-devel mailing list