Bug 287430 - devel/qt6-tools: fail to package: qdoc:No such file or directory
Summary: devel/qt6-tools: fail to package: qdoc:No such file or directory
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-kde (group)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-06-10 18:37 UTC by Ivan Rozhuk
Modified: 2025-06-13 11:26 UTC (History)
5 users (show)

See Also:
jhale: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Rozhuk 2025-06-10 18:37:33 UTC
...
Qt Tools:
  Qt Assistant ........................... yes
  libclang found ......................... no
  Clang-based lupdate parser ............. no
  Qt Widgets Designer .................... yes
  Qt Distance Field Generator ............ yes
  Qt Linguist ............................ yes
  pixeltool .............................. yes
  qdbus .................................. yes
  QDoc ................................... no
  Qt Attributions Scanner ................ yes
  qtdiag ................................. yes
  qtplugininfo ........................... yes
...

===>  Installing for qt6-tools-6.9.1
===>  Checking if qt6-tools is already installed
===>   Registering installation for qt6-tools-6.9.1 as automatic
pkg-static: Unable to access file /tmp/ports/usr/ports/devel/qt6-tools/work/stage/usr/local/bin/qdoc6:No such file or directory
pkg-static: Unable to access file /tmp/ports/usr/ports/devel/qt6-tools/work/stage/usr/local/lib/qt6/bin/qdoc:No such file or directory
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/qt6-tools
Comment 1 Jason E. Hale freebsd_committer freebsd_triage 2025-06-10 21:07:19 UTC
Configure is not finding a suitable libclang, which is required for qdoc to build.

Which version of llvm are you using? Have you changed llvm in DEFAULT_VERSIONS? Only llvm(17|18|19|20) are supported by upstream, but our testing was only done with the current default llvm19.
Comment 2 Chad Jacob Milios 2025-06-10 21:51:56 UTC
(In reply to Jason E. Hale from comment #1)

me too same error, same config summary, after the 6.9.1 update today. i'm on 13.5-RELEASE/amd64

root@Rick:/usr/ports/devel/qt6-tools # make -DBATCH -VLLVM_PREFIX
/usr/local/llvm19

root@Rick:/usr/ports/devel/qt6-tools # more /etc/make.conf 
DEFAULT_VERSIONS= bdb=18 gcc=14 go=1.24 guile=3.0 java=24 linux=rl9 llvm=19 mono=6.8 mysql=9.1 nodejs=24 perl5=5.40 pgsql=17 php=8.4 python=3.11 ruby=3.4 samba=4.20 ssl=openssl34 tcltk=9.0 varnish=7

root@Rick:/usr/ports/devel/qt6-tools # ls /usr/local/llvm19/lib/cmake/clang/
AddClang.cmake                  ClangConfigVersion.cmake        ClangTargets.cmake
ClangConfig.cmake               ClangTargets-release.cmake


furthermore configure target had said: 

WARNING: 
QDoc will not be compiled, probably because clang's C and C++ libraries could not be located.
This means that you cannot build the Qt documentation. You may need to set the CMake variables
CMAKE_PREFIX_PATH or LLVM_INSTALL_DIR to the location of your llvm installation.
Other than clang's libraries, you may need to install another package, such as clang itself, to
provide the ClangConfig.cmake file needed to detect your libraries. Once this file is in place,
the configure script may be able to detect your system-installed libraries without further
environment variables.

NOTE: You WILL also need to set the FEATURE_clang CMake variable to ON to re-try finding the
dependencies.

On macOS, you can use Homebrew's llvm package.
Run `brew install llvm` and then configure with

 `configure LLVM_INSTALL_DIR=/opt/homebrew/opt/llvm FEATURE_clang=ON` for macOS arm64
or
 `configure LLVM_INSTALL_DIR=/usr/local/opt/llvm FEATURE_clang_ON` for macOS x86_64.

On Linux, you can try installing the clang package from your distribution's package manager.
On Debian / Ubuntu run `sudo apt install libclang-dev`.
On Fedora / RHEL run `sudo dnf install clang-devel`.
On ArchLinux run `sudo pacman -S clang llvm`.

Alternatively, you can use the prebuilt binaries hosted by Qt.
These let you link LLVM/Clang libraries statically, but only support Release builds on Windows.
https://download.qt.io/development_releases/prebuilt/libclang/qt/

After installing, reconfigure with

 `/qt_src/configure FEATURE_clang=ON` for a top-level build that includes the qttools repo
or
 `/qt_build/qt-configure-module /path/to/qttools FEATURE_clang=ON` for a per-submodule build

WARNING: QDoc will not be compiled because it requires libclang 17 or newer.
WARNING: The Clang-based lupdate parser will not be available. Suitable LLVM and Clang C++ libraries have not been found. You will need to set the FEATURE_clangcpp CMake variable to ON to re-evaluate this check.
Comment 3 Chad Jacob Milios 2025-06-10 22:09:38 UTC
evidently this was killing it for me:

CMake Warning at cmake/FindWrapLibClang.cmake:72 (find_package):
  Could not find a configuration file for package "Clang" that exactly
  matches requested version "20.1.6".

  The following configuration files were considered but not accepted:

    /usr/local/llvm19/lib/cmake/clang/ClangConfig.cmake, version: 19.1.7


temporarily removed llvm20 and qt6-tools built and packaged fine. perhaps theres a CMake var we can explicitly set to LLVM_VERSION to keep CMake from getting cute?
Comment 4 Jason E. Hale freebsd_committer freebsd_triage 2025-06-10 23:27:01 UTC
(In reply to Chad Jacob Milios from comment #3)
I see what the problem is in your case and hopefully that is also Ivan’s problem, because it should be a relatively simple fix.

The problem is FindWrapLibClang.cmake [1] iterates over QDOC_SUPPORTED_CLANG_VERSIONS defined in .cmake.conf [2] and selects the newest version it finds. This will fail if a user has a newer version of llvm installed than the version set in DEFAULT_VERSIONS.

One solution would be to define QDOC_SUPPORTED_CLANG_VERSIONS to LLVM_VERSION with a little extra logic to also supply the minor version.

[1] https://code.qt.io/cgit/qt/qttools.git/tree/cmake/FindWrapLibClang.cmake?h=6.9.1
[2] https://code.qt.io/cgit/qt/qttools.git/tree/.cmake.conf?h=6.9.1
Comment 5 commit-hook freebsd_committer freebsd_triage 2025-06-11 09:39:24 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=496d5f7bf5e2697546731bc0728ba1ff99ebfd13

commit 496d5f7bf5e2697546731bc0728ba1ff99ebfd13
Author:     Jason E. Hale <jhale@FreeBSD.org>
AuthorDate: 2025-06-11 08:55:23 +0000
Commit:     Jason E. Hale <jhale@FreeBSD.org>
CommitDate: 2025-06-11 09:38:55 +0000

    devel/qt6-tools: Avoid LLVM version mismatches

    In 6.9.0, the Tools component of Qt introduced more restrictive checks
    for versions of LLVM it supports and automatically selects the newest
    version installed without an offical override option. This is
    problematic for us, because if a user has a version of LLVM installed
    greater than what they have set in DEFAULT_VERSIONS, it will cause
    configuration errors due to CMake mismatching the latest version of LLVM
    found with the version we actually want to build against.

    Patch to only supply the version of LLVM we intend to build against to
    the checks. These checks need at least the major and minor version of
    LLVM to work. Unfortunately, LLVM_VERSION, which only provide the major
    version isn't enough, so there's some silliness which is hopefully
    explained well enough in the Makefile and in the patch for future
    hackers.

    PR:             287430
    Reported by:    Ivan Rozhuk <rozhuk.im@gmail.com>, Chad Jacob Milios <milios@ccsys.com>

 devel/qt6-tools/Makefile                      | 16 ++++++++++++----
 devel/qt6-tools/files/patch-.cmake.conf (new) | 19 +++++++++++++++++++
 2 files changed, 31 insertions(+), 4 deletions(-)
Comment 6 Jason E. Hale freebsd_committer freebsd_triage 2025-06-11 09:42:49 UTC
Ivan and Chad, does 496d5f7bf5e2 fix the problem for you?
Comment 7 Ivan Rozhuk 2025-06-11 12:16:18 UTC
(In reply to Jason E. Hale from comment #6)
Yes, thanks!
Comment 8 Chad Jacob Milios 2025-06-11 21:52:03 UTC
(In reply to Jason E. Hale from comment #6)

TL;DR: sure does! good to close, thanks!
maybe ${:!${LLVM_CONFIG} --version!:R} tho, no?

--More--(33%)

Retested with llvm20 in place and llvm19 selected. Thank you so much for the excellent [and prompt!] work going that extra mile rather than telling us to punt it to poudriere

--More--(END)
`cat $MUSINGS`

Nothing at all wrong with how youve implemented it but for your consideration (for this or the next thing) since clearly u r a bona fide wizard of ports & bmake:

1. ${:!foo!} [vs] `foo` (modifiers can chain, lazy eval vs late)
2. ${LLVM_CONFIG} --version [vs] ${MAKE} -C $elsewhere -VFOO (maybe sparse tree)
3. :S/./ /g:[1..2]:ts. [vs] :R (if paranoid of !~ x.y.z in the future/multiverse)
4. for good measure an explicit :tw (are semantics of :S/foo/ / very well defined?)

so all chained together its:
${:!${LLVM_CONFIG} --version!:S/./ /g:tw:[1..2]:ts.}

Surely im overthinking it but i'm glad to discuss the pitch black magic with a fellow o.g. :) iron sharpens iron. So then, might you happen to know a more clear/concise method than the line noise that is my suggestion 3 yet which makes fewer assumptions than :R must? (i mean an elegant one i'm overlooking; obvs we can contrive a dozen various uses of :C///) This sorta $1.split("$2").splice(${3:-0},${4:-HUGE_VAL}).join("${5:-$2}") situation is pretty common, no?

Just 1 & 2, given our manageable expectations are pretty reliably met:
${:!${LLVM_CONFIG} --version!:R}
Comment 9 Jason E. Hale freebsd_committer freebsd_triage 2025-06-13 11:26:55 UTC
(In reply to Chad Jacob Milios from comment #8)
>Thank you so much for the excellent [and prompt!] work going that extra mile 
Of course! I want Qt to be working for as many users as possible on FreeBSD. :)

>rather than telling us to punt it to poudriere
Well, I really wanted to stick to the issue, but since you brought it up, non-poudriere users comprise about 95% of PRs I field for Qt bugs. I had an angry rant prepared, but I realized that would be counterproductive and just add to my reputation of being an "old man yelling at a cloud". [1]

>2. ${LLVM_CONFIG} --version [vs] ${MAKE} -C $elsewhere -VFOO (maybe sparse tree)
Great suggestion! I forgot all about LLVM_CONFIG. The major.minor version is all that is absolutely required...full version works just as well, so no need to be too creative with points 3 and 4. Perhaps I was being a bit too over-dramatic with the :R modifier.

I'll likely rework this to use LLVM_CONFIG for Qt 6.9.2, but since my dumb hack is apparently
working, I'll just leave it as is until then.

[1] https://memepediadankmemes.fandom.com/wiki/Old_Man_Yells_at_Cloud