guix-devel
[Top][All Lists]
Advanced

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

Re: Question about Haskell packages


From: Taylan Ulrich Bayırlı/Kammer
Subject: Re: Question about Haskell packages
Date: Wed, 14 Oct 2015 19:19:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Paul van der Walt <address@hidden> writes:

> Hello Guix,

Hello!

> Yesterday i thought to myself that it would be cool to mess around with
> Idris <http://www.idris-lang.org>, on of the dependently-typed
> languages.  Turns out it depends on quite a lot of Hackage packages!  I
> steamed ahead, and now i have packaged all the dependencies.
>
> One weird thing i ran into though, is that frequently, a library L1 will
> build fine, but when you use it as an input to some other library L2,
> the configure phase will fail, saying that L1 is broken, since
> it is missing its dependencies D1..Dn.  Iyzsong suggested on IRC that i
> do like nixpkgs does [0] and simply add all dependencies as
> propagated-inputs.  That should solve that issue, but since i don't 100%
> understand what's going on, i thought it wise to ask you, wise and
> attractive users of Guix, for advice.

This sounds very similar to the pkg-config related problems that were
discussed a while back.  (It's a complicated topic, but the thread
starts here if you're interested:
https://lists.gnu.org/archive/html/guix-devel/2015-03/msg00565.html )

Long story short, some systems like pkg-config, and I guess Hackage
(maybe it just uses pkg-config?) aren't smart enough to understand that
a run-time dependency L2 of library L1 might be satisfied without having
any development meta-data of L2 installed during the compilation of a
program P which depends on L1.  Only L1's meta-data is really needed for
program P's compilation, but pkg-config is being "extra smart" and also
checks whether L2's meta-data is present, thinking that if it isn't, it
must mean L1 is broken because it lacks a dependency, as you noted.

(In the case of pkg-config, the meta-data is in "libfoo.pc" files in
$PKG_CONFIG_PATH.)

To work around that, we make L2 a "propagated input" of L1, meaning
whenever L1 is installed in some environment, the whole of L2 is also
installed (rather than making L2 invisible in the environment, although
it's really on the system and L1 refers to it via absolute file names).

Someone with specific knowledge of Hackage might want to confirm whether
it really has the exact same behavior as pkg-config, or whether there's
a better workaround for it.  If it doesn't, then indeed you need to turn
some inputs of L1 into propagated inputs.

Hope that helps,
Taylan



reply via email to

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