On Sun, Aug 19, 2018 at 11:55 PM Ben Cooksley <bcooks...@kde.org> wrote: > > On Sun, 19 Aug 2018, 12:19 David Faure, <fa...@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 <fa...@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 <fa...@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, fa...@kde.org, http://www.davidfaure.fr >> Working on KDE Frameworks 5 >> >> >>
