This is reproducible when dev-qt/qtchooser is not present. It is going away in the future. Build system has: > find_program(QHG_LOCATION > NAMES > qhelpgenerator > qhelpgenerator-qt5 # e.g. CentOS 7 > ) This can't be switched off and will just lead to the files not being present if qhelpgenerator is not found. Traceback (most recent call last): File "/usr/lib/portage/python3.9/doins.py", line 594, in <module> sys.exit(main(sys.argv[1:])) File "/usr/lib/portage/python3.9/doins.py", line 582, in main if _doins( File "/usr/lib/portage/python3.9/doins.py", line 434, in _doins return install_runner.install_file(source, os.path.dirname(dest)) File "/usr/lib/portage/python3.9/doins.py", line 370, in install_file return self._ins_runner.run(source, dest_dir) File "/usr/lib/portage/python3.9/doins.py", line 179, in run sstat = os.stat(source) FileNotFoundError: [Errno 2] No such file or directory: b'/var/tmp/portage/dev-libs/uriparser-0.9.4/work/uriparser-0.9.4_build/doc/*.qch'
Hi Andreas, I'm happy to improve on this situation. Do you have any particular solutions in mind? Best Sebastian
Yes, I've just looked it up from ECM's FindQHelpGenerator.cmake module: Replace the above code snippet with: > find_package(Qt5Help QUIET) - This will provide Qt5::qhelpgenerator TARGET, which you can use to replace QHG_LOCATION in the root CMakeLists.txt file. - In the ebuild, you can then use $(cmake_use_find_package qt5 Qt5Help) - To stay compatible with doc/Doxyfile.in, set QHG_LOCATION like this: > get_target_property(QHG_LOCATION Qt5::qhelpgenerator LOCATION) > mark_as_advanced(QHG_LOCATION)
Please also check out my port to cmake.eclass and cleanup old versions: https://github.com/gentoo/gentoo/pull/19675
(In reply to Andreas Sturmlechner from comment #2) > Yes, I've just looked it up from ECM's FindQHelpGenerator.cmake module: > > Replace the above code snippet with: > > find_package(Qt5Help QUIET) > - This will provide Qt5::qhelpgenerator TARGET, which you can use to replace > QHG_LOCATION in the root CMakeLists.txt file. > - In the ebuild, you can then use $(cmake_use_find_package qt5 Qt5Help) > - To stay compatible with doc/Doxyfile.in, set QHG_LOCATION like this: > > get_target_property(QHG_LOCATION Qt5::qhelpgenerator LOCATION) > > mark_as_advanced(QHG_LOCATION) Thanks — very helpful! After playing with it: - I found that unmodified uriparser 0.9.4 already supports passing explicit -DQHG_LOCATION=/some/path/here to CMake if we wanted to do that in the ebuild - I have not yet found any way to create a command line that would print the path to the qhelpgenerator executable so maybe that's best left to CMake. qtchooser seems to only run things, pus you said it would go away. - For letting CMake do the work I have created a pull request #103 [1] based on your ideas. I welcome review, if you're interested. - With regard to the ebuild: - "cmake_use_find_package qt5 Qt5Help" seems be useful to bypass one selected call to CMake function "find_package". My impression is we will not need that for the current 0.9.4 or the upcoming 0.9.5/1.0.0 ebuild. I might be missing something — what is the idea with our case, could you elaborate? - We could either apply one of the commits from upstream pull request #103 [1] once it is merged to make 0.9.4-r1 or wait until the next release. Which do you prefer? Best, Sebastian [1] https://github.com/uriparser/uriparser/pull/103
(In reply to Sebastian Pipping from comment #4) > [..] qtchooser seems to only run things, pus you said it would > go away. -pus +plus
(In reply to Sebastian Pipping from comment #4) > - With regard to the ebuild: > > - "cmake_use_find_package qt5 Qt5Help" seems be useful to bypass > one selected call to CMake function "find_package". My impression > is we will not need that for the current 0.9.4 or the upcoming > 0.9.5/1.0.0 ebuild. I might be missing something — what is the > idea with our case, could you elaborate? You need a handle for IUSE=qt5. Otherwise, the install image is not dependent on the setting of the use flag but purely on the availability of qthelpgenerator. However, the - imo completely superfluous - fallback to detect _QHG_LOCATION via find_program defeats the purpose to get rid of the automagic.
(In reply to Andreas Sturmlechner from comment #6) > You need a handle for IUSE=qt5. Otherwise, the install image is not > dependent on the setting of the use flag but purely on the availability of > qthelpgenerator. Good point. > However, the - imo completely superfluous - fallback to detect _QHG_LOCATION > via find_program defeats the purpose to get rid of the automagic. I see. I have dropped the backwards compat part from https://github.com/uriparser/uriparser/pull/103 now so that… - future use of cmake_use_find_package in the ebuild should be able to reduce auto-magic to zero while - mainstream users with little interest in .qhp files are still not bothered about missing qhelpgenerator during the build. What do you think?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=665ce4aca4c111011407b42293a86faa051dd777 commit 665ce4aca4c111011407b42293a86faa051dd777 Author: Sebastian Pipping <sping@gentoo.org> AuthorDate: 2021-03-18 17:46:10 +0000 Commit: Sebastian Pipping <sping@gentoo.org> CommitDate: 2021-03-18 17:51:42 +0000 dev-libs/uriparser: 0.9.5 + QA fixes Closes: https://bugs.gentoo.org/773430 Signed-off-by: Sebastian Pipping <sping@gentoo.org> Package-Manager: Portage-3.0.17, Repoman-3.0.2 dev-libs/uriparser/Manifest | 1 + dev-libs/uriparser/uriparser-0.9.5.ebuild | 56 +++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+)
