Hi Rob! On Thu, 25 Aug 2022 at 21:37, Rob Savoury <savo...@savos.tech> wrote: > > 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.
Indeed you did, sorry for that! > 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. Yes, ideally we need to solve this directly upstream. > 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. The two bugs are totally fine! but first we need liblitehtml to move forward first. Again, thanks for your effort and time! -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
