Hi Lisandro, It's a good suggestion about doing a MR using Salsa in future, an option that I didn't consider (three years ago I did make a Salsa account for one task with another package, so an MR is possible).
There are actually two issues here. A key one is certainly with the missing litehtmlConfig.cmake file, which I did actually mention in the first paragraph of the bug report. So until litehtml is updated it does block this bug being resolved. However, there is another issue with qt6-tools CMake logic causing the CMake configure phase to error out when trying to build with a system litehtml package. Here are the errors (can be confirmed by attempting to build qt6-tools with a version of litehtml that does include litehtmlConfig.cmake): ``` CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt6/QtFlagHandlingHelpers.cmake:171 (target_compile_definitions): Cannot specify compile definitions for target "litehtml" which is not built by this project. Call Stack (most recent call first): src/assistant/CMakeLists.txt:34 (qt_internal_set_exceptions_flags) CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt6/QtFlagHandlingHelpers.cmake:190 (get_target_property): get_target_property() called with non-existent target "litehtml". Call Stack (most recent call first): src/assistant/CMakeLists.txt:35 (qt_disable_warnings) CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt6/QtFlagHandlingHelpers.cmake:190 (get_target_property): get_target_property() called with non-existent target "gumbo". Call Stack (most recent call first): src/assistant/CMakeLists.txt:37 (qt_disable_warnings) ``` These errors cause FTBFS unless src/assistant/CMakeLists.txt in qt6-tools is also patched. In the patch I attached to this bug report is then a proposed patch to include in qt6-tools package. The proposed patch to include in qt6-tools package simply removes the three offending CMake commands that cause the above quoted errors. So it appears to be an upstream bug with CMake logic used by qt6-tools as well (though I haven't filed a bug with Qt directly yet as I first wanted to report it here). It seems that upstream does not properly cater to using a system litehtml library after all. Also a change to the header path for litehtml will be required if a version of litehtml > 0.5 is packaged by the maintainer due to newer litehtml moving headers into a litehtml directory. Thus, the patch that I proposed to include in qt6-tools would also modify this file: src/assistant/qlitehtml/src/container_qpainter_p.h The header path in that file would be changed from litehtml.h to litehtml/litehtml.h as per litehtml > 0.5 source. Therefore it does certainly seem easier just to use the litehtml source included in qt6-tools in the end! However, as litehtml is already packaged in Debian and given that qt6-tools has a BD on liblitehtml-dev that was not actually being used it is indeed a bug (and with both packages, as explained above). At least in terms of the intended outcomes! So that's why I filed the two bug reports.
