This worked with Qt 5.9 on the CI and locally with 5.10 too, but the CI seems to be unhappy for openSUSE/Qt 5.10 and Windows/Qt 5.10 (it works on openSUSE/Qt 5.9 and FreeBSD/Qt 5.10):

• https://build.kde.org/job/Frameworks%20kdoctools%20kf5-qt5%20SUSEQt5.10/46/
• https://build.kde.org/job/Frameworks%20kdoctools%20kf5-qt5%20WindowsMSVCQt5.10/35/
• https://build.kde.org/job/Frameworks%20kdoctools%20kf5-qt5%20FreeBSDQt5.10/
• https://build.kde.org/job/Frameworks%20kdoctools%20kf5-qt5%20SUSEQt5.9/32/

Do the logs ring any bell about the possible reason?

In D14817#308903, @ltoscano wrote:

This worked with Qt 5.9 on the CI and locally with 5.10 too, but the CI seems to be unhappy for openSUSE/Qt 5.10 and Windows/Qt 5.10 (it works on openSUSE/Qt 5.9 and FreeBSD/Qt 5.10):

• https://build.kde.org/job/Frameworks%20kdoctools%20kf5-qt5%20SUSEQt5.10/46/

14:08:13 Scanning dependencies of target po-es-docs-foobar-index-cache-bz2
14:08:13 [ 8%] Generating po/es/docs/foobar/index.cache.bz2
14:08:13 gmake[2]: * [CMakeFiles/po-es-docs-foobar-index-cache-bz2.dir/build.make:62: po/es/docs/foobar/index.cache.bz2] Error 1
14:08:13 gmake[1]: * [CMakeFiles/Makefile2:73: CMakeFiles/po-es-docs-foobar-index-cache-bz2.dir/all] Error 2
14:08:13 gmake: *** [Makefile:130: all] Error 2
reason not visible - I suggest to add VERBOSE=1 to the related make comment

• https://build.kde.org/job/Frameworks%20kdoctools%20kf5-qt5%20WindowsMSVCQt5.10/35/

14:11:43 Test command failed: C:/Craft/CI/windows-msvc2017_64-cl-debug/dev-utils/cmake/bin/cmake.exe
14:11:43 CMake Error at C:/CI/workspace/Frameworks kdoctools kf5-qt5 WindowsMSVCQt5.10/autotests/kdoctools-install/test.cmake:20 (message):
14:11:43 destdir/share/man/man1/checkXML5.1 was not found
This may be caused by not specifing an absolute path in test.cmake e.g.

-set(MANPATH destdir/share/man)
-set(HTMLPATH destdir/share/doc/HTML)
+set(MANPATH ${CMAKE_INSTALL_PREFIX}/share/man)
+set(HTMLPATH ${CMAKE_INSTALL_PREFIX}/share/doc/HTML)

---test-command ${CMAKE_COMMAND}  -P "${CMAKE_CURRENT_SOURCE_DIR}/kdoctools-install/test.cmake
+--test-command ${CMAKE_COMMAND}  "-DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_CURRENT_BINARY_DIR}/kdoctools-install/destdir" -P "${CMAKE_CURRENT_SOURCE_DIR}/kdoctools-install/test.cmake"

• https://build.kde.org/job/Frameworks%20kdoctools%20kf5-qt5%20FreeBSDQt5.10/

#1​6 Aug 14, 2018 2:07 PM
Finished: SUCCESS
no issue visible -> tests are disabled

• https://build.kde.org/job/Frameworks%20kdoctools%20kf5-qt5%20SUSEQt5.9/32/

#3​2 Aug 14, 2018 2:07 PM
Finished: SUCCESS
no issue visible -> tests are disabled

I applied a fix to use absolute pathes. Unfortunally windows builds have an additional issue:

https://build.kde.org/job/Frameworks%20kdoctools%20kf5-qt5%20WindowsMSVCQt5.10/36/console

21:26:34 -- Installing: C:/CI/workspace/Frameworks kdoctools kf5-qt5 WindowsMSVCQt5.10/build/autotests/kdoctools-install/destdir/bin/data/man/man1/checkXML5.1
...
21:26:34   C:/CI/workspace/Frameworks kdoctools kf5-qt5 WindowsMSVCQt5.10/build/autotests/kdoctools-install/destdir/share/man/man1/checkXML5.1  was not found

-> msvc builds uses a different install dir
This is caused by https://cgit.kde.org/extra-cmake-modules.git/tree/kde-modules/KDEInstallDirs.cmake#n531

This change has caused CI wide breakage and makes kdoctools unrelocatable. It needs to be reverted urgently, and Dependency Builds triggered to roll it out to all the non Frameworks jobs which have already picked this up.

This is the remaining issue on non Windows KDE CI Qt 5.10

https://build.kde.org/job/Frameworks%20kdoctools%20kf5-qt5%20SUSEQt5.10/49/consoleFull

07:02:43 cd "/home/jenkins/workspace/Frameworks kdoctools kf5-qt5 SUSEQt5.10/autotests/kdoctools-install" && "/home/jenkins/workspace/Frameworks kdoctools kf5-qt5 SUSEQt5.10/build/bin/meinproc5" --check --cache /home/jenkins/workspace/Frameworks\ kdoctools\ kf5-  qt5\ SUSEQt5.10/build/autotests/kdoctools-install/po/es/docs/foobar/index.cache.bz2 po/es/docs/foobar/index.docbook
07:02:43 gmake[2]: *** [CMakeFiles/po-es-docs-foobar-index-cache-bz2.dir/build.make:65: po/es/docs/foobar/index.cache.bz2] Error 1

In D14817#309281, @bcooksley wrote:

This change has caused CI wide breakage and makes kdoctools unrelocatable.

This has been fixed with commit https://phabricator.kde.org/R238:4e48476f47414f1077a181ef56a19f7d9289d50d

See other comments for the remaining issues.

In D14817#309283, @habacker wrote:

This is the remaining issue on non Windows KDE CI Qt 5.10

https://build.kde.org/job/Frameworks%20kdoctools%20kf5-qt5%20SUSEQt5.10/49/consoleFull

07:02:43 cd "/home/jenkins/workspace/Frameworks kdoctools kf5-qt5 SUSEQt5.10/autotests/kdoctools-install" && "/home/jenkins/workspace/Frameworks kdoctools kf5-qt5 SUSEQt5.10/build/bin/meinproc5" --check --cache /home/jenkins/workspace/Frameworks\ kdoctools\ kf5-  qt5\ SUSEQt5.10/build/autotests/kdoctools-install/po/es/docs/foobar/index.cache.bz2 po/es/docs/foobar/index.docbook
07:02:43 gmake[2]: *** [CMakeFiles/po-es-docs-foobar-index-cache-bz2.dir/build.make:65: po/es/docs/foobar/index.cache.bz2] Error 1

Funny, that this works with Qt 5.9 https://build.kde.org/job/Frameworks%20kdoctools%20kf5-qt5%20SUSEQt5.9/ and Qt 5.11 (locally tested) - it only happens with Qt 5.10

In D14817#309285, @habacker wrote:

Funny, that this works with Qt 5.9 https://build.kde.org/job/Frameworks%20kdoctools%20kf5-qt5%20SUSEQt5.9/ and Qt 5.11 (locally tested) - it only happens with Qt 5.10

Because I cannot reproduce this issue on a local build there is the question how to be let meinproc5 more verbose

According to https://cgit.kde.org/kdoctools.git/tree/src/meinproc.cpp#n51 uses meinproc5 qCCritical(KDocToolsLog) - How can this be enabled on KDE CI ?

In D14817#309281, @bcooksley wrote:

Dependency Builds triggered to roll it out to all the non Frameworks jobs which have already picked this up.

How to do this ?

You aren't seeing the error the CI system sees because your build prefix still exists. Try removing that and the error it has should show up on your local system

In D14817#309295, @habacker wrote:

According to https://cgit.kde.org/kdoctools.git/tree/src/meinproc.cpp#n51 uses meinproc5 qCCritical(KDocToolsLog) - How can this be enabled on KDE CI ?

Got it - see https://phabricator.kde.org/R238:81a3d951169b7f575c0a09c2cf19eb911fab9882

The Windows failure looks like a problem with handling of DESTDIR - probably due to reliance on it being handled by $DESTDIR instead of %DESTDIR% (which is the correct syntax for Windows)

In D14817#309303, @bcooksley wrote:

Try removing that and the error it has should show up on your local system

I see.
Since this problem has been fixed in kdoctools git repo and kdoctools has been rebuilt on KDE CI, packages like kio, which depend on kdoctools, are automatically rebuilt, as is the case with OBS?

In D14817#309332, @bcooksley wrote:

The Windows failure looks like a problem with handling of DESTDIR - probably due to reliance on it being handled by $DESTDIR instead of %DESTDIR% (which is the correct syntax for Windows)

No , it is a install path mismatch. According to https://build.kde.org/job/Frameworks%20kdoctools%20kf5-qt5%20WindowsMSVCQt5.10/39/console the files are installed below <...>/bin/data (https://cgit.kde.org/extra-cmake-modules.git/tree/kde-modules/KDEInstallDirs.cmake) but test.qmake expects them in <...>/share (https://cgit.kde.org/kdoctools.git/tree/autotests/kdoctools-install/test.cmake)

On Windows the correct path to use is $prefix/bin/data/... as that is what QStandardPaths expects.
The location $prefix/share/ won't work on Windows, so the test will need to handle that case.

Because test.qmake do not know anything about KDE install path layout those pathes need to be specified in the ctest config in autotests/CMakeLists.txt I guess

--test-command ${CMAKE_COMMAND}
    "-DKDE_INSTALL_MANDIR=${KDE_INSTALL_MANDIR}"
    "-DKDE_INSTALL_DOCBUNDLEDIR=${KDE_INSTALL_DOCBUNDLEDIR}"
    "-DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_CURRENT_BINARY_DIR}/kdoctools-install/destdir"
    -P "${CMAKE_CURRENT_SOURCE_DIR}/kdoctools-install/test.cmake")

and in test.qmake

...
set(MANPATH ${CMAKE_INSTALL_PREFIX}/${KDE_INSTALL_MANDIR})
set(HTMLPATH ${CMAKE_INSTALL_PREFIX}/${KDE_INSTALL_DOCBUNDLEDIR})
 ...

another option would be to force the install path in the cmake call

add_test(kdoctools_install ${CMAKE_CTEST_COMMAND}
  --build-and-test
  "${CMAKE_CURRENT_SOURCE_DIR}/kdoctools-install"
  "${CMAKE_CURRENT_BINARY_DIR}/kdoctools-install"
  --build-generator ${CMAKE_GENERATOR}
  --build-makeprogram ${CMAKE_MAKE_PROGRAM}
  --build-target install
  --build-options
      "-DCMAKE_MODULE_PATH=${CMAKE_MODULE_PATH}"
      "-DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_CURRENT_BINARY_DIR}/kdoctools-install/destdir"
      "-DKF5DocTools_DIR=${CMAKE_BINARY_DIR}/cmake"
      "-DKDOCTOOLS_CUSTOMIZATION_DIR=${KDOCTOOLS_CUSTOMIZATION_DIR}"
      "-DKDOCTOOLS_ENABLE_HTMLHANDBOOK=1"
     ...
    "-DKDE_INSTALL_MANDIR=share/man"
    "-DKDE_INSTALL_DOCBUNDLEDIR=share/doc/HTML"

In D14817#309370, @bcooksley wrote:

On Windows the correct path to use is $prefix/bin/data/... as that is what QStandardPaths expects.
The location $prefix/share/ won't work on Windows, so the test will need to handle that case.

Agreed, as long as there is Qt on Windows not patched to also use unix style path layout, which is the case on OBS

In D14817#309388, @habacker wrote:

Agreed, as long as there is Qt on Windows not patched to also use unix style path layout, which is the case on OBS

but this case should be covered by ECM module 'KDEInstallDirs'.

If KDE_INSTALL_XXX always return a relative dir , it should be save to use