[Nix-dev] Pls help with installation of gtk-qt-engine on NixOS

[Eelco Dolstra]

Hi,

Christian Wagner wrote:

> I installed NixOS, after trying out Nix for a while on Debian Etch. I really
> like the unique concept of Nix and NixOS! I was able to get KDE working and
> still have a lot of questions after reading the brilliant thesis and the
> documentation. I would be grateful, if somebody could help this NixOS
> beginner.
> 
> I built a simple NixOS gkt-based package called Transmission-0.72, which
> works  well. Noticing how ugly the Gtk2 apps look under KDE, I then tried to
> make a package from gtk-qt-engine-0.7 for KDE

Hm, it would be great to have this working :-)

> , which compiled fine, but
> failed in the install step with an error:
> 
> mkdir: cannot create directory
> `/nix/store/yz24...-gtk+-2.8.20/share/gtk-qt-engine': Permission denied
> 
> On Debian, gtk-qt-engine installs in /usr/lib/gtk-2.0/2.4.0/engines, and
> apparently the installer tries to do something similar here. As the nix-store
> of gtk2 is read only, the gtk-qt-engine obviously has to go somewhere else.
> 
> How do you usually solve problems like this, where one application wants to
> install parts of itself into the directory tree of another application? Do
> any of the build-support scripts apply to this?

Yes, there are a few examples of this.  It's always a nasty problem, and there's
no general solution.  You need to

1) convince the builder to install the files under $out; and

2) somehow make the application in question find the files at runtime.

An example is Subversion, which tries to install its Apache module (when built
with httpServer = true) under the Apache prefix.  In the Subversion case both
problems are easy to solve.  The build script just says

  makeFlags="APACHE_LIBEXECDIR=$out/modules $makeFlags"

And in httpd.conf you can just specify the full path to the Subversion module,
so it works fine at runtime.

An example that we haven't solved very well yet is Eclipse, which looks for its
plugins under its own prefix.  Building plugins outside of the Eclipse prefix is
easy, but Eclipse apparently doesn't have a plugin search path, so you can't
actually use them.  The current solution is to build the plugins *as part of
Eclipse* (so Eclipse is a function that takes a list of plugins, see
all-packages.nix), but this means that all of Eclipse is rebuilt when you add a
plugin.  Clearly not very nice.  The real solution would probably to patch
Eclipse to add a plugin search path (probably a fairly trivial hack).

In the case of gtkqtengine, you need to hack the build process so that the
engine is installed in $out instead of in the gtk prefix.  Probably a bit of
makefile hackery will do that (or maybe there's a configure flag?).

The tricky part is probably to get GTK to actually use the engine.  I don't know
how you configure that at runtime, but if GTK only searches for engines under
its own prefix, then some patching is necessary.  Hopefully it's possible to
specify an absolute path, though.

> === Below is the nix expression used to build the package ===
> 
> {stdenv, fetchurl, kdelibs, perl, expat, pkgconfig, cairo, libjpeg, glib,
> gtk, atk, pango, libbonobo, libart_lgpl, libIDL, libX11, libXext, qt}:
> 
> stdenv.mkDerivation {
>   name = "gtkqtengine-0.7";
> 
>   src = fetchurl {
>     url = http://gtk-qt.ecs.soton.ac.uk/files/0.7/gtk-qt-engine-0.7.tar.bz2;
>     md5 = "27ca211621f38c45b1c4c9e9ef1f84b0";
>   };
> 
>   KDEDIR = kdelibs;
> 
>   configureFlags = "
>     --without-arts";
> 
>   buildInputs = [kdelibs perl expat pkgconfig cairo libjpeg glib gtk atk
> pango libbonobo libart_lgpl libIDL libX11 libXext qt];
> 
>   meta = {
>     description = "theme engine using Qt for GTK+ 2.x from within KDE";
>   };
> }
> 
> ===
> 
> Please point out all the glaring omissions in this nix-expression ;-)

Looks fine to me :-)  Instead of libX11 and libXext you can also pass the "x11"
wrapper package in all-packages.nix, which contains both of these.

-- 
Eelco Dolstra | http://www.cs.uu.nl/~eelco