qt6: init at 6.2.0 by milahu · Pull Request #141883 · NixOS/nixpkgs

milahu · 2021-10-16T14:44:31Z

closed in favor of #169296

Motivation for this change

add latest version of qt, compile from source

Status

all builds are passing
libraries are usable in cmake projects
qmake support is not implemented, but has low priority (qmake is deprecated, qmake2cmake)

estimated build times on 4x2.4GHz

 80 min qtdeclarative
 40 min qtbase
 20 min qtwayland
720 min qtwebengine = 12 hours, similar to chromium

 [todo] pyside - takes surprisingly long
        C++ is heavy to parse, maybe caching could be better -> upstream issue

build

cd path/to/nixpkgs
time nix-build . -A qt6.qtbase --keep-failed 2>&1 | tee qt6.qtbase.$(date +%s).log
ls -d /nix/store/*-qtbase-6.2.?{,-{dev,bin}}

qt6 apps

https://github.com/milahu/awesome-qt6

contributing

feel free to help me with this beast ...

common problems (and solutions) with packaging qt6 for nixos: packaging-qt6.md

todo

Things done

nixos-discourse · 2021-10-16T15:21:52Z

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/attempting-to-build-qt6/10551/8

pkgs/development/libraries/qt-6/6.2/default.nix

pkgs/development/libraries/qt-6/6.2/fetch.sh

pkgs/top-level/qt6-packages.nix

pkgs/development/libraries/qt-6/qtModule.nix

pkgs/development/libraries/qt-6/modules/qtwebkit.nix

pkgs/development/libraries/qt-6/modules/qtwebengine.nix

pkgs/development/libraries/qt-6/modules/qtmultimedia.nix

pkgs/development/libraries/qt-6/modules/qtgamepad.nix

pkgs/development/libraries/qt-6/modules/qtdeclarative.nix

pkgs/development/libraries/qt-6/modules/qtbase.nix

nrdxp · 2022-04-12T23:45:19Z

@milahu are there any merge blockers? I'd be glad to merge this before the feature freeze window closes if possible.

peterhoeg · 2022-04-13T02:21:50Z

Qt 6.3 was released y'day: https://www.qt.io/blog/qt-6.3-released

peterhoeg · 2022-04-13T02:22:20Z

@ttuegel , do you have time to take a look at this?

peterhoeg · 2022-04-13T02:27:36Z

And just to add this - I understand that 6.2 is an LTS release, but KDE as eventually the main downstream consumer of Qt6 is presumably going to be requiring the latest and thus 6.3 is likely to be a requirement for that.

Of course, there is nothing preventing us from carrying both the latest LTS as well as the latest and greatest.

peterhoeg · 2022-04-13T02:30:11Z

pkgs/applications/audio/strawberry/default.nix

 , qtbase
-, qtx11extras
+, qtx11extras ? null # qt5
+, qt5compat ? null # qt6


qt5compat isn't used

peterhoeg · 2022-04-13T02:31:29Z

pkgs/applications/audio/strawberry/default.nix

    taglib
    qtbase
    qtx11extras
+  ] ++ lib.optionals (lib.versions.major qtbase.version == "5") [


I wondering if we should introduce isQt5 and isQt6 helpers like what we have for Python as this check (or a variation of it) is most likely going to be littered all over the place.

peterhoeg · 2022-04-13T02:32:45Z

pkgs/development/libraries/qt-6/README.md

@@ -0,0 +1,81 @@
+# Qt 5 Maintainer's Notes


There's a few references to Qt 5 that should Qt 6.

milahu · 2022-04-13T08:01:03Z

@milahu are there any merge blockers?

"someone" (sorry, i have no energy for this) would need to squash all the qt6 commits
and separate them from the "switch app to qt6" (etc) commits
(also see my todo list in the first post)

apart from that ... not that i know of. it's "basically working"

I'd be glad to merge this before the feature freeze window closes if possible.

yepp. better than "death by perfectionism"

Artturin · 2022-04-13T08:06:08Z

Adding qt6 isn't a breaking change so it can be merged anytime and backported

ttuegel · 2022-04-13T16:55:44Z

pkgs/development/libraries/qt-6/README.md

+## Minor Updates
+
+Let `$major` be the major version number, e.g. `5.9`.
+
+1. Change the version number in the `$major/fetch.sh`.
+2. Run `./maintainers/scripts/fetch-kde-qt.sh pkgs/development/libraries/qt-5/$major`
+   from the top of the Nixpkgs tree.
+
+See below if it is necessary to update any patches.
+
+## Major Updates
+
+Let `$major` be the new major version number, e.g. `5.10`.
+
+1. Copy the subdirectory from the previous major version to `$major`.
+2. Change the version number in `$major/fetch.sh`.
+3. Run `./maintainers/scripts/fetch-kde-qt.sh pkgs/development/libraries/qt-5/$major`
+   from the top of the Nixpkgs tree.
+4. Add a top-level attribute in `pkgs/top-level/all-packages.nix` for the new
+   major version.
+5. Change the `qt5` top-level attribute to point to the new major version.
+6. If the previous major version is _not_ a long-term support release,
+   remove it from Nixpkgs.
+
+See below if it is necessary to update any patches.


All of this should change with Qt 6 because there are not LTS releases anymore. We should only track the latest version in Nixpkgs. (Aside from that, having multiple Qt 5 versions in Nixpkgs never worked correctly anyway.)

ttuegel · 2022-04-13T16:57:16Z

pkgs/development/libraries/qt-6/README.md

+
+See below if it is necessary to update any patches.
+
+## Patches


None of this is applicable anymore.

ttuegel · 2022-04-13T16:59:27Z

pkgs/development/libraries/qt-6/modules/qt5compat.nix

+, qtbase
+, qtdeclarative
+, libiconv
+  # FIXME Configure summary: qt5compat is not using libiconv. bug in qt6?


To use libiconv in some module like qt5compat, we probably need to enable the corresponding feature in the qtbase build.

ttuegel · 2022-04-13T17:02:18Z

pkgs/development/libraries/qt-6/modules/qtwebkit.nix

+in
+
+qtModule {
+  pname = "qtwebkit";


I really think we should drop qtwebkit from Qt 6.

ttuegel · 2022-04-13T17:03:04Z

pkgs/development/libraries/qt-6/packaging-qt6.md

+qt5 used `configure`. for example `./configure -system-ffmpeg`
+
+qt6 uses cmake, so we need ...


Does this mean that all configureFlags should be removed from (for example) the qtbase build?

iirc, some options go to configure, other options go to cmake

ive added a script to the readme to list the available cmake options

oxalica · 2022-04-14T11:30:34Z

Note: tdesktop 3.6.3 requires Qt 6 to build now, thus is blocked by this PR.
https://github.com/telegramdesktop/tdesktop/releases/tag/v3.6.3

K900 · 2022-04-18T08:56:21Z

Anything holding this back still? tdesktop 3.7.0 also requires Qt6 now, and the current version requires some jank to keep going (see #169180).

NickCao · 2022-04-18T09:03:32Z

I think the biggest blocker is whether it builds.

NickCao · 2022-04-18T15:24:44Z

Just picked this up https://github.com/NickCao/nixpkgs/tree/qt6 and bumped it to qt 6.3.0, surprisingly most of the things builds with minor fixes (with qtwebengine as the only exception). tdesktop 3.7.0 builds and works fine with this.

NickCao · 2022-04-18T15:59:36Z

~~Still having some trouble in getting IME (fcitx5) to work.~~ export QT_PLUGIN_PATH=/run/current-system/sw/lib/qt-6.3.0/plugins fixes the issue.
The lack of this particular patch should be the root cause: https://github.com/NickCao/nixpkgs/blob/qt6/pkgs/development/libraries/qt-5/5.12/qtbase.patch.d/0010-qtbase-qtpluginpath.patch

Kranzes · 2022-04-18T16:26:12Z

Just picked this up https://github.com/NickCao/nixpkgs/tree/qt6 and bumped it to qt 6.3.0, surprisingly most of the things builds with minor fixes (with qtwebengine as the only exception). tdesktop 3.7.0 builds and works fine with this.

I also tested tdesktop 3.7.0 from your branch, works fine.

milahu · 2022-04-18T17:15:07Z

@NickCao thx : )

im curious how 8b2eed21b7ecdb8f788810f21ea927c0cabea8c5 works ...

Details

iirc, my goal was to make the qt libs usable in cmake projects
by adding the line

  INTERFACE_LINK_DIRECTORIES "\${_((QT_MODULE_NAME))_NIX_OUT}/lib"

before the line

  INTERFACE_INCLUDE_DIRECTORIES ...

in the generated *.cmake files
otherwise cmake would say "package found but files are missing"

so, in my remote diagnosis, your version should break the tdesktop build, but apparently it works?

maybe this was fixed between qt 6.2 and 6.3
how do your generated *.cmake files look when you grep -C10 for INTERFACE_INCLUDE_DIRECTORIES?

ttuegel · 2022-04-18T18:34:12Z

The lack of this particular patch should be the root cause: https://github.com/NickCao/nixpkgs/blob/qt6/pkgs/development/libraries/qt-5/5.12/qtbase.patch.d/0010-qtbase-qtpluginpath.patch

This patch caused a lot of headaches for Qt 5 and in the strongest way possible, I would encourage us not to make that mistake again. Maintainers should set up the correct wrappers for their applications.

NickCao · 2022-04-18T23:30:33Z

im curious how 8b2eed2 works ...

Me myself don't know how either, I removed that line simply because it was patching too much, breaking unrelated cmake files specifically the one for libdrm vendoered in qtbase. And somehow, it just works.

Artturin · 2022-04-19T00:12:03Z

Still needs lots of cleanup and resyncing the improvements to the qt5 packaging made during the time this pr has been open

The ? nulls should he replaced with something better too

NickCao · 2022-04-19T02:25:46Z

Tinkered a little bit around the cmake patching hacks, found that it seems all the patched files are named SomeQtComponentTargets{,-release}.cmake and is generated by cmake. Can we just patch the template from which the cmake files are generated and solve this once and for all?

NickCao · 2022-04-19T06:45:36Z

By applying a questionable and overfitting patch atop cmake, I managed to cut the hacky list of regex by half.
NickCao@8cd5854

NickCao · 2022-04-19T07:37:54Z

By further neglecting support for qmake, the final approach is now clean and clear:
NickCao@f5aa39f
After all cmake is not complaining anything about that.

NickCao · 2022-04-19T09:50:49Z

Just noticed that the qt plugins depends on the main output in their rpaths, so what's the point of splitting them into another output?

NickCao · 2022-04-19T09:54:25Z

Also as the coexisting multiple minor qt versions approach has never really worked out, dropping that also looks like a nice choice for me.

milahu · 2022-04-19T14:56:02Z

most of the things builds with minor fixes (with qtwebengine as the only exception)

what's the issue with qtwebengine?

NickCao · 2022-04-19T15:24:01Z

./third_party/webgpu-cts/src/tools/deno: unsupported interpreter directive "#!/usr/bin/env -S deno run --unstable --allow-read --allow-write --allow-env --no-check" (set dontPatchShebangs=1 and handle shebang patching yourself)

milahu · 2022-04-19T15:34:03Z

oh .. stupid patchShebangs is confused by the -S option #77539

nixpkgs/pkgs/build-support/setup-hooks/patch-shebangs.sh

Lines 64 to 71 in bf27ea9

    
           if [[ "$oldPath" == *"/bin/env" ]]; then 
        
               # Check for unsupported 'env' functionality: 
        
               # - options: something starting with a '-' 
        
               # - environment variables: foo=bar 
        
               if [[ $arg0 == "-"* || $arg0 == *"="* ]]; then 
        
                   echo "$f: unsupported interpreter directive \"$oldInterpreterLine\" (set dontPatchShebangs=1 and handle shebang patching yourself)" >&2 
        
                   exit 1 
        
               fi

you could try

{
  postPatch = ''
    sed -i.bak 's|^#!/usr/bin/env -S deno|#! ${deno}/bin/deno|' ./third_party/webgpu-cts/src/tools/deno
    diff -u ./third_party/webgpu-cts/src/tools/deno{.bak,} || true; exit 1 # debug
  '';

milahu · 2022-05-05T08:51:39Z

closing in favor of #169296

keeping the branch qt-6-init