bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pango


From: Andreas Enge
Subject: Re: Pango
Date: Sat, 15 Jun 2013 10:12:24 +0200
User-agent: KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; )

The include files for pango reside in
   include/pango-1.0/pango/
Then the main include file
   include/pango-1.0/pango/pango.h
includes lines like
   #include <pango/pango-attributes.h>
without the pango-1.0.

I see three solutions:

One can modify the CPATH to include pango-1.0; I do not know how to do this 
automatically so that each and every dependency of pango profits from it.

One can modify each header file (of gtk+, for instance) including 
pango/pango.h to include pango-1.0/pango/pango.h instead, which would be 
rather tedious in the long run.

Or one can add a symlink
   pango -> pango-1.0/pango
with the following patch:
   (arguments
    `(#:phases
       (alist-replace
        'install
        (lambda* (#:key outputs #:allow-other-keys #:rest args)
         (let ((install (assoc-ref %standard-phases 'install))
               (include (string-append (assoc-ref outputs "out") 
"/include")))
           (apply install args)
           ;; Unravel one directory, since pango.h includes directly from
           ;; pango/, not pango-1/pango/.
           (symlink (string-append include "/pango-1.0/pango")
                    (string-append include "/pango"))))

Would the third solution be okay? I already used it for freetype, but there 
the additional directory layer was announced to be suppressed in the near 
future.

As the symlink would only be inside the nix store path for this particular 
package, we could still (in case it comes out) have packages depend on 
pango-2, while others depend on pango-1.0, for instance. But it would 
prevent users from installing pango-2 and pango-1.0 at the same time in 
their user environment, as both would contain the symlink include/pango.


A similar problem occurs with cairo: The header files are in
   include/cairo/cairo.h,
whereas gtk+ has lines such as
   #include <cairo.h>.
Here I would prefer the second solution, as one directory layer to regroup 
the header files of a package such as cairo looks reasonable to me to avoid 
clutter.

What do you think?


And a minor question: Would you prefer the package name "gtk" or "gtk+"?

Andreas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]