all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Andreas Enge <andreas@enge.fr>
To: bug-guix@gnu.org
Subject: Re: Pango
Date: Sat, 15 Jun 2013 10:12:24 +0200	[thread overview]
Message-ID: <201306151012.24926.andreas@enge.fr> (raw)
In-Reply-To: <201306142334.44593.andreas@enge.fr>

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	other threads:[~2013-06-15  8:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-13 21:19 Demain Andreas Enge
2013-06-13 21:37 ` Demain Andreas Enge
2013-06-13 23:49   ` Demain Cyril Roelandt
2013-06-14  7:52     ` Demain Andreas Enge
2013-06-14 12:29   ` Demain Ludovic Courtès
2013-06-14 21:25     ` Pango Andreas Enge
2013-06-14 21:34       ` Pango Andreas Enge
2013-06-15  8:12         ` Andreas Enge [this message]
2013-06-15  8:29           ` Pango Andreas Enge
2013-06-15 13:17           ` Pango Ludovic Courtès
2013-06-15 13:31             ` Pango Andreas Enge
2013-06-15 13:49               ` Pango Ludovic Courtès
2013-06-15 14:07                 ` Pango Andreas Enge
     [not found]                   ` <87sj0j3yzh.fsf@gnu.org>
2013-06-15 20:55                     ` Pango Andreas Enge
2013-06-15 12:57         ` Pango Ludovic Courtès
2013-06-15  1:58       ` Pango Cyril Roelandt
2013-06-15  7:13         ` Pango Andreas Enge
2013-06-15 13:14           ` Pango Ludovic Courtès
2013-06-15 12:56       ` Pango Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201306151012.24926.andreas@enge.fr \
    --to=andreas@enge.fr \
    --cc=bug-guix@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.