Packaging Qt "Addon" modules

Development
1

In addition to Qt’s “Essential Framework” modules, there are a whole host of “Framework Add-Ons”, which aren’t included in the main source download that the nixpkgs.qt5 modules are based on (e.g. http://download.qt.io/official_releases/qt/5.12/5.12.7/submodules/). However, they are generally tied to the main Qt version. Their sources can be fetched from https://code.qt.io/ using the Qt version as a git tag. See here for a list of core and addon modules.

As far as I can tell, none of the addon modules are currently packaged in nixos. Many of them are somewhat niche in their appeal, so I am not suggesting that we should try and include them all in nixpkgs. However, I am curious how to go about packaging some of them (Today, I’m mostly interested in playing with qtmqtt, but I’d like to know others’ thoughts on the “right” way to integrated them into nixpkgs).

  1. Given that they follow the main Qt version, should they be grouped under the main qt5 attribute? i.e. qt5.qtmqtt, not just qtmqtt (and consequently have multiple versions built from different sources where appropriate, e.g. both qt59.qtmqtt and qt512.qtmqtt if both qt versions were currently supported).
  2. Aside from keeping the version in sync, do they need to be integrated into the main qt-5 module build system in some way from a technical point of view, or is using libsForQt sufficient? (They clearly don’t belong in the auto-generated pkgs/development/libraries/qt-5/5.12/srcs.nix, as they are fetched from a different place.)

I experimented with integrating addons into qt5 here.

1 Like
2

I have no useful expertise here, but I’ll give this a bump because there’s an application (phd2) I would like to package that depends on Qt5Positioning.

3

Yes, they will need to be grouped under qt5 so that Nixpkgs builds a different version for each version of Qt that we carry.

That depends. We build each module stand-alone so that we can share Qt libraries between derivations, but this is not really supported upstream. If the other add-on modules do not officially support stand-alone builds, then they need to be integrated into the existing Nixpkgs system for building Qt modules. Otherwise, if these add-ons do support stand-alone builds, then I don’t see any reason to treat them differently from other libraries.