Bug#1018004: qt6-tools: does not build and link with system litehtml

[Rob Savoury]

Package: src:qt6-tools
Version: 6.3.1-2
Severity: normal
Tags: patch

Dear Maintainer,

This package does not currently build and link with system litehtml
as apparently desired. A build dependency on liblitehtml-dev seems
to indicate an intention for the package to use the system litehtml
for the Qt Assistant tool, though the currently packaged litehtml
(0.5-3) is not successfully found via CMake due missing the needed
litehtmlConfig.cmake file. So this bug also applies to litehtml.

Failure to build/link with the system litehtml is easily confirmed
by looking at the assistant-qt6 package [1] which shows no depends
on liblitehtml0 as would be expected if system litehtml was used.
For previous versions of qt6-tools (ie. 6.2.4) the usual CMake
status output shows the failure to find system litehtml during the
dh_auto_configure phase which includes the following output [2]:

[...]
-- The following OPTIONAL packages have not been found:

* Qt6QmlCompilerPlus
* litehtml
[...]

Builds of Qt 6.3.1 packages including qt6-tools have much reduced
CMake output for some reason, including on Ubuntu Launchpad (not
sure why this is so ?) and so the "not been found" message is not
shown in the build logs (ie. for latest 6.3.1-2 [3] package).

Looking into src:qt6-tools there is a 3rdparty directory [4] which
includes a full copy of litehtml source as at commit 971eadc on
2021-10-28 [5]. This is confirmed by doing a git clone of litehtml
at that exact commit, with no differences seen between that version
of litehtml source and litehtml source included in src:qt6-tools.

Builds of src:qt6-tools that successfully use and link with system
litehtml have been tested by me, through packaging the exact same
version of litehtml (0.5+git20211028) as included in src:qt6-tools.
A patch is then also required due issues with Qt CMake code (trying
to set Qt defs only applicable to source code in the Qt6 Tools
project) and a changed location of litehtml headers (after 0.5).

Builds of src:qt6-tools 6.2.4 against src:litehtml 0.5+git20211028
that demonstrate successful use and linking with the system litehtml
are now available at a recently created Launchpad PPA [6] for Ubuntu
users. So this bug does also affect qt6-tools 6.2.4-2~bpo11+1 as
found in bullseye-backports repository, confirmed by above mentioned
build logs and again by checking depends for assistant-qt6 [7].

Basic testing of the /usr/lib/qt6/bin/assistant binary (installed
via assistant-qt6 binary package) from the Launchpad PPA shows that
it appears to work as intended. Adding precompiled Qt help (.qch)
files via preferences allows browsing of the content successfully.

Attached is a proposed patch which applies cleanly to the qt6-tools
6.3.1-2 package as currently found in Sid. An adaptation of changes
made by this patch was used for 6.2.4 with the mentioned Launchpad
PPA builds, as could be done for the Bullseye qt6-tools backport.
This patch will only be useful once litehtml 0.5+git20211028 is also
packaged, due that version being required for a successful build.

A bug report will subsequently be filed for litehtml detailing the
required version and also other fixes (including updating a patch
to litehtml CMakeLists.txt) for building and linking to work with
qt6-tools successfully. Both packages will have to be updated for
that result to be achieved.

Thank you for your work maintaining the Qt6 packages.

[1] https://packages.debian.org/sid/assistant-qt6
[2]
https://buildd.debian.org/status/fetch.php?pkg=qt6-tools&arch=amd64&ver=6.2.4-3&stamp=1657216677&raw=0
[3]
https://buildd.debian.org/status/fetch.php?pkg=qt6-tools&arch=amd64&ver=6.3.1-2&stamp=1660602816&raw=0
[4] src:qt6-tools -> src/assistant/qlitehtml/src/3rdparty/litehtml
[5] https://github.com/litehtml/litehtml/commit/971eadc
[6] https://launchpad.net/~savoury1/+archive/ubuntu/qt-6-2
[7] https://packages.debian.org/bullseye-backports/assistant-qt6

[Rob Savoury]

For reference the bug filed against src:litehtml related to this is:

#1018006 - litehtml: qt6-tools does not build/link with this version

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018006

[Lisandro Damián Nicanor Pérez Meyer]

Control: block 1018004 by 1018006

Hi Rob!

Thanks a lot for your patch! If possible, next time try to create a MR
in https://salsa.debian.org/qt-kde-team/qt6/qt6-tools/ , that makes it
much easier for us to review.

Now looking at the code the real issue is on litehtml itself. By
modifying src/assistant/qlitehtml/src/CMakeLists.txt to make a verbose
find_package():

```
CMake Warning at src/assistant/qlitehtml/src/CMakeLists.txt:15 (find_package):
By not providing "Findlitehtml.cmake" in CMAKE_MODULE_PATH this
project has
asked CMake to find a package configuration file provided by
"litehtml",
but CMake did not find one.

Could not find a package configuration file provided by "litehtml"
with any
of the following names:

litehtmlConfig.cmake
litehtml-config.cmake

Add the installation prefix of "litehtml" to CMAKE_PREFIX_PATH or set
"litehtml_DIR" to a directory containing one of the above files. If
"litehtml" provides a separate development package or SDK, be sure it
has
been installed.
```

Looking at liblitehtml-dev:

```
$ dpkg -L liblitehtml-dev | grep -i cmake
/usr/lib/x86_64-linux-gnu/cmake
/usr/lib/x86_64-linux-gnu/cmake/litehtml
/usr/lib/x86_64-linux-gnu/cmake/litehtml/litehtmlTargets-none.cmake
/usr/lib/x86_64-linux-gnu/cmake/litehtml/litehtmlTargets.cmake
```

it is not providing the right CMake files.

So the fix really lies on liblitehtml. qttools already has the right
code in order to make it work, liblitehtml needs to ship the right
cmake files.


--
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

[Rob Savoury]

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.

[Lisandro Damián Nicanor Pérez Meyer]

Hi Rob!

On Thu, 25 Aug 2022 at 21:37, Rob Savoury <sav...@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!

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!

[Patrick Franz]

Hi,

I tried enabling system litehtml by adding liblitehtml-dev as a B-D
(version 0.6 of litehtml supposedly fixes the issue) and litehtml is indeed found by qttools.

However, the build fails because of

In file included from /<<PKGBUILDDIR>>/src/assistant/qlitehtml/src/container_qpainter.cpp:5:
/<<PKGBUILDDIR>>/src/assistant/qlitehtml/src/container_qpainter_p.h:8:10: fatal error: litehtml.h: No such file or directory
8 | #include <litehtml.h>
| ^~~~~~~~~~~~
compilation terminated.

It seems that while system litehtml is now found, /usr/include/litehtml/ is not included by gcc/g++:

[327/632] /usr/lib/ccache/c++ -DQLITEHTML_STATIC_LIBRARY -DQT_CORE_LIB -DQT_GUI_LIB
-DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_JAVA_STYLE_ITERATORS -DQT_RESTRICTED_CAST_FROM_ASCII
-DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -I/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/src/assistant/qlitehtml/src/qlitehtml_autogen/include
-I/<<PKGBUILDDIR>>/src/assistant/qlitehtml/src -isystem /usr/include/x86_64-linux-gnu/qt6/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt6
-isystem /usr/include/x86_64-linux-gnu/qt6/QtCore -isystem /usr/lib/x86_64-linux-gnu/qt6/mkspecs/linux-g++
-isystem /usr/include/x86_64-linux-gnu/qt6/QtGui -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -w -fPIC -std=c++17
-MD -MT src/assistant/qlitehtml/src/CMakeFiles/qlitehtml.dir/container_qpainter.cpp.o
-MF src/assistant/qlitehtml/src/CMakeFiles/qlitehtml.dir/container_qpainter.cpp.o.d
-o src/assistant/qlitehtml/src/CMakeFiles/qlitehtml.dir/container_qpainter.cpp.o
-c /<<PKGBUILDDIR>>/src/assistant/qlitehtml/src/container_qpainter.cpp


--
Med vänliga hälsningar

Patrick Franz

[Patrick Franz]

Hi again,

actually, screw the last message...I should've read and tried the
entire(!!) patch and not just a part of it :-(.