mirror of
https://github.com/SebastianWendel/nixpkgs.git
synced 2024-11-05 17:56:46 +01:00
75 lines
3.4 KiB
XML
75 lines
3.4 KiB
XML
<section xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
|
xml:id="sec-language-qt">
|
|
<title>Qt</title>
|
|
|
|
<para>
|
|
Qt is a comprehensive desktop and mobile application development toolkit for
|
|
C++. Legacy support is available for Qt 3 and Qt 4, but all current
|
|
development uses Qt 5. The Qt 5 packages in Nixpkgs are updated frequently to
|
|
take advantage of new features, but older versions are typically retained
|
|
until their support window ends. The most important consideration in
|
|
packaging Qt-based software is ensuring that each package and all its
|
|
dependencies use the same version of Qt 5; this consideration motivates most
|
|
of the tools described below.
|
|
</para>
|
|
|
|
<section xml:id="ssec-qt-libraries">
|
|
<title>Packaging Libraries for Nixpkgs</title>
|
|
|
|
<para>
|
|
Whenever possible, libraries that use Qt 5 should be built with each
|
|
available version. Packages providing libraries should be added to the
|
|
top-level function <varname>mkLibsForQt5</varname>, which is used to build a
|
|
set of libraries for every Qt 5 version. A special
|
|
<varname>callPackage</varname> function is used in this scope to ensure that
|
|
the entire dependency tree uses the same Qt 5 version. Import dependencies
|
|
unqualified, i.e., <literal>qtbase</literal> not
|
|
<literal>qt5.qtbase</literal>. <emphasis>Do not</emphasis> import a package
|
|
set such as <literal>qt5</literal> or <literal>libsForQt5</literal>.
|
|
</para>
|
|
|
|
<para>
|
|
If a library does not support a particular version of Qt 5, it is best to
|
|
mark it as broken by setting its <literal>meta.broken</literal> attribute. A
|
|
package may be marked broken for certain versions by testing the
|
|
<literal>qtbase.version</literal> attribute, which will always give the
|
|
current Qt 5 version.
|
|
</para>
|
|
</section>
|
|
|
|
<section xml:id="ssec-qt-applications">
|
|
<title>Packaging Applications for Nixpkgs</title>
|
|
|
|
<para>
|
|
Call your application expression using
|
|
<literal>libsForQt5.callPackage</literal> instead of
|
|
<literal>callPackage</literal>. Import dependencies unqualified, i.e.,
|
|
<literal>qtbase</literal> not <literal>qt5.qtbase</literal>. <emphasis>Do
|
|
not</emphasis> import a package set such as <literal>qt5</literal> or
|
|
<literal>libsForQt5</literal>.
|
|
</para>
|
|
|
|
<para>
|
|
Qt 5 maintains strict backward compatibility, so it is generally best to
|
|
build an application package against the latest version using the
|
|
<varname>libsForQt5</varname> library set. In case a package does not build
|
|
with the latest Qt version, it is possible to pick a set pinned to a
|
|
particular version, e.g. <varname>libsForQt55</varname> for Qt 5.5, if that
|
|
is the latest version the package supports. If a package must be pinned to
|
|
an older Qt version, be sure to file a bug upstream; because Qt is strictly
|
|
backwards-compatible, any incompatibility is by definition a bug in the
|
|
application.
|
|
</para>
|
|
|
|
<para>
|
|
When testing applications in Nixpkgs, it is a common practice to build the
|
|
package with <literal>nix-build</literal> and run it using the created
|
|
symbolic link. This will not work with Qt applications, however, because
|
|
they have many hard runtime requirements that can only be guaranteed if the
|
|
package is actually installed. To test a Qt application, install it with
|
|
<literal>nix-env</literal> or run it inside <literal>nix-shell</literal>.
|
|
</para>
|
|
</section>
|
|
</section>
|