Qt 6 was installed as follows:
0$ sudo pkg install library/qt6
As a workaround, the Qt6_DIR CMake variable can be set manually:
0$ cmake -B build -DBUILD_GUI=ON -DQt6_DIR=/usr/lib/qt/6.6/lib/amd64/cmake/Qt6
Alternatively, the Qt6_ROOT CMake or environment variable can be used:
0$ env Qt6_DIR=/usr/lib/qt/6.6/lib/amd64 cmake -B build -DBUILD_GUI=ON
Moved from https://github.com/hebasto/bitcoin/issues/234.
It sure is annoying when system packages are installed to a location where they cannot be found by default. On the other hand, package maintainers may have their reasons for doing that. There are probably multiple packages which depend on Qt6 and are built with CMake. It is very likely that package maintainers have their build environment set up for that.
Trying to work around that “issue” creates a maintenance burden for us and potentially for package maintainers too, because our workaround may cause conflicts with their build environment setup. The most portable solution is to do - believe it or not - nothing at all.
If we want to provide binary packages for download on a website, we take the role of package maintainers. In packaging scripts, we need to setup a build environment so that all dependencies can be found. There are countless ways to do that. Two are mentioned above, other approaches are listed in the documentation of the find_package command. Such build scripts ideally should be maintained separate from the project, like in a separate repository.
If we want to provide binary packages for download on a website, we take the role of package maintainers. In packaging scripts, we need to setup a build environment so that all dependencies can be found. There are countless ways to do that.
The only way we will produce anything binary, that would end up being distributed on our website, is via our Guix build; so any approach taken needs to happen inside Guix (all blobs/binaries must be reproducible).
Such build scripts ideally should be maintained separate from the project, like in a separate repository.
Can you elaborate? I don’t think I’d agree with splitting up our release scripts, into separate repositories.
build-*.md can be added with any needed details. Whether or not to do a guix build can be decided then as well.