purpose unittests on Windows
Ben Cooksley
bcooksley at kde.org
Fri Aug 24 10:23:42 BST 2018
On Sun, Aug 19, 2018 at 11:55 PM Ben Cooksley <bcooksley at kde.org> wrote:
>
> 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)
Any update on this?
In regards to the QT_PLUGIN_PATH issue above, this also appears to be
causing tests in KDevelop to fail (causing runs there to take 8
hours..) so i'd like to find a solution to that somewhat soonish if we
can.
Cheers,
Ben
>
>
>>
>> > 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
>>
>>
>>
More information about the Kde-frameworks-devel
mailing list