purpose unittests on Windows

Sun Aug 19 11:19:06 BST 2018

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

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

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

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

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

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