<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Sun, 19 Aug 2018, 12:19 David Faure, <<a href="mailto:faure@kde.org">faure@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On lundi 13 août 2018 11:06:12 CEST Ben Cooksley wrote:<br>
> On Mon, Aug 13, 2018 at 1:16 AM David Faure <<a href="mailto:faure@kde.org" target="_blank" rel="noreferrer">faure@kde.org</a>> wrote:<br>
> > On samedi 11 août 2018 07:02:18 CEST Ben Cooksley wrote:<br>
> > > On Fri, Aug 10, 2018 at 7:28 PM David Faure <<a href="mailto:faure@kde.org" target="_blank" rel="noreferrer">faure@kde.org</a>> wrote:<br>
> > > > Any idea why purpose can't find the KIO http and file protocols -- on<br>
> > > > Windows?<br>
> > > > <br>
> > > > <a href="https://build.kde.org/view/Frameworks/job/Frameworks%20purpose%20kf5-q" rel="noreferrer noreferrer" target="_blank">https://build.kde.org/view/Frameworks/job/Frameworks%20purpose%20kf5-q</a><br>
> > > > t5%2<br>
> > > > 0WindowsMSVCQt5.10/76/testReport/junit/(root)/TestSuite/alternativesmo<br>
> > > > delt<br>
> > > > est/<br>
> > > > <br>
> > > > That's very odd, because the dependency from purpose on kio is there<br>
> > > > in<br>
> > > > kde-build-metadata (it wouldn't build otherwise), and using kio_file<br>
> > > > from<br>
> > > > other frameworks surely works (e.g. in KParts).<br>
> > > > <br>
> > > > The lookup for protocols looks for "kf5/kio" under all Qt plugin<br>
> > > > directories, i.e. $QT_PLUGIN_PATH.<br>
> > > > <br>
> > > > The CI log says<br>
> > > > QT_PLUGIN_PATH = 'C:\CI\workspace\Frameworks purpose<br>
> > > > kf5-qt5<br>
> > > > WindowsMSVCQt5.10\install-prefix\lib\plugins;C:\Craft\CI\windows-msvc2<br>
> > > > 017<br>
> > > > _64-cl-debug\lib\qca-qt5'<br>
> > > > <br>
> > > > => is there a kf5\kio subdir in C:\CI\workspace\Frameworks purpose<br>
> > > > kf5-qt5<br>
> > > > WindowsMSVCQt5.10\install-prefix\lib\plugins ?<br>
> > > <br>
> > > I've checked and the following seem to be present in that directory,<br>
> > > which looks correct to me:<br>
> > > <br>
> > > Mode LastWriteTime Length Name<br>
> > > ---- ------------- ------ ----<br>
> > > -a---- 8/10/2018 8:39 PM 274944 file.dll<br>
> > > -a---- 8/10/2018 8:40 PM 352256 ftp.dll<br>
> > > -a---- 8/10/2018 8:40 PM 185856 ghelp.dll<br>
> > > -a---- 8/10/2018 8:39 PM 185856 help.dll<br>
> > > -a---- 8/10/2018 8:45 PM 946688 http.dll<br>
> > > -a---- 8/10/2018 8:40 PM 189440 remote.dll<br>
> > > -a---- 8/10/2018 8:40 PM 122880 trash.dll<br>
> > > <br>
> > > Is there any debug output we can enable to see how it is searching for<br>
> > > the plugins?<br>
> > <br>
> > I have now added debug output to kcoreaddons and kio, and the result is:<br>
> > Checking for plugins in ("C:/CI/workspace/Frameworks purpose kf5-qt5<br>
> > WindowsMSVCQt5.10/build/bin/kf5/kio",<br>
> > "C:/Craft/CI/windows-msvc2017_64-cl-debug/plugins/kf5/kio")> <br>
> > This list doesn't include the above directory, C:\CI\workspace\Frameworks<br>
> > purpose kf5-qt5 WindowsMSVCQt5.10\install-prefix\lib\plugins.<br>
> > <br>
> > Yet, ECMAddTests.cmake adds to QT_PLUGIN_PATH, it doesn't overwrite it...<br>
> > I wonder if set(PATHSEP "\\;") is correct though (why double backslash?)<br>
> > QCoreApplication::libraryPaths reads that env var and splits it using<br>
> > QDir::listSeparator() which is ';' on Windows. Kevin, any reason for the<br>
> > backslash?<br>
> > Do you see any other reason for this to fail, otherwise?<br>
> <br>
> Hi all,<br>
> <br>
> I've done some investigation work on this on the CI system this<br>
> morning and it seems that it isn't even necessary to set<br>
> QT_PLUGIN_PATH within ECMAddTests (at least on Windows anyway)<br>
<br>
I'm confused. Do you mean that *NOT* setting QT_PLUGIN_PATH actually fixes the <br>
finding of kio_file, while setting that env var (as in the CI) breaks finding <br>
it?<br>
I can't make sense of that, because QCoreApplication::libraryPaths only *adds* <br>
the contents of QT_PLUGIN_PATH into the list of dirs, it doesn't replace or <br>
remove anything...<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Sorry - not setting QT_PLUGIN_PATH in the CMake code makes it work.</div><div dir="auto"><br></div><div dir="auto">The CI Tooling sets it when it runs so leaving that undisturbed seems to make it happy.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> QDEBUG : AlternativesModelTest::bigBufferTest() org.kde.kcoreaddons:<br>
> Checking for plugins in ("C:/CI/workspace/Frameworks purpose kf5-qt5<br>
> WindowsMSVCQt5.10/install-prefix/lib/plugins/kf5/kio",<br>
> "C:/Craft/CI/windows-msvc2017_64-cl-debug/lib/qca-qt5/kf5/kio",<br>
> "C:/Craft/CI/windows-msvc2017_64-cl-debug/plugins/kf5/kio",<br>
> "C:/CI/workspace/Frameworks purpose kf5-qt5<br>
> WindowsMSVCQt5.10/build/bin/kf5/kio")<br>
<br>
That's definitely more search paths than what CI currently shows:<br>
<br>
Checking for plugins in ("C:/CI/workspace/Frameworks purpose kf5-qt5 <br>
WindowsMSVCQt5.10/build/bin/kf5/kio", "C:/Craft/CI/windows-msvc2017_64-cl-<br>
debug/plugins/kf5/kio")<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yep. That is the additional ones the CI sets.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> QDEBUG : AlternativesModelTest::bigBufferTest() kf5.kio.core:<br>
> "C:/CI/workspace/Frameworks purpose kf5-qt5<br>
> WindowsMSVCQt5.10/install-prefix/lib/plugins/kf5/kio/file.dll"<br>
> supports protocols ("file")<br>
<br>
That's success indeed.<br>
<br>
> Unfortunately doing this doesn't fix the test as it's unable to find<br>
> kioslave.exe, even though it exists in $workspace/install-prefix/bin/<br>
> so not sure what's happening there:<br>
> " Can not find 'kioslave' executable at 'C:/CI/workspace/Frameworks purpose<br>
> kf5-qt5 WindowsMSVCQt5.10/build/bin,<br>
> C:/Craft/CI/windows-msvc2017_64-cl-debug/bin,<br>
> C:/CI/workspace/Frameworks kio kf5-qt5<br>
> WindowsMSVCQt5.10/install-prefix/bin'"<br>
<br>
According to the last entry in this path, it's looking into the install prefix <br>
for *KIO*, which is indeed where I would expect kioslave.exe to be.<br>
But you're saying below that somehow kioslave.exe ends up in the install <br>
prefix for *purpose* instead?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yeah. Each of those workspaces is throw away and is erased at the end of each run of a job. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">This test will be working on Linux and FreeBSD because we use $home/install-prefix there due to Wayland framework hardcoding limitations. </div><div dir="auto"><br></div><div dir="auto">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) </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Directory of C:\CI\workspace\Frameworks purpose kf5-qt5<br>
> WindowsMSVCQt5.10\install-prefix\bin<br>
> 08/12/2018 06:21 AM 62,464 kioslave.exe<br>
<br>
That's the purpose install prefix. How did kioslave.exe get there?<br>
<br>
Seems like the wrong place --- it's logical that the purpose unittest are not <br>
going to depend on anything in the purpose install prefix, we're trying to run <br>
tests with the framework being uninstalled.<br>
<br>
The issue is likely that kioslave is installed into libexec and not bin.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yeah, it will work for all other executables as they're found in PATH.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Was there some manual copying done long ago to fix that, but at the time <br>
copying into the install prefix was enough, while nowadays that can't work <br>
(now that the install prefix isn't supposed to exist yet)?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Ben</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Copying from kio's libexec to kio's bin should fix that.<br>
<br>
-- <br>
David Faure, <a href="mailto:faure@kde.org" target="_blank" rel="noreferrer">faure@kde.org</a>, <a href="http://www.davidfaure.fr" rel="noreferrer noreferrer" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE Frameworks 5<br>
<br>
<br>
<br>
</blockquote></div></div></div>