all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Question about Haskell packages
@ 2015-10-14 15:11 Paul van der Walt
  2015-10-14 17:19 ` Taylan Ulrich Bayırlı/Kammer
  0 siblings, 1 reply; 4+ messages in thread
From: Paul van der Walt @ 2015-10-14 15:11 UTC (permalink / raw)
  To: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]

Hello Guix,

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.

I will polish the patches before sending them, so don't hold your breath
yet.  I'm currently also trying to upgrade the packages to the Haskell
Platform 7.10.2-a versions.  Turns out GHC is slow to build.

Ah, another question: do you people think it would be worthwhile /
useful to provide a haskell-platform-$ver metapackage which depends on
all the exact versions bundled in that HP?  See [1] for a list.

Thank you for your advice,
p.

0. <https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/hackage-packages.nix>
1. <https://www.haskell.org/platform/contents.html>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question about Haskell packages
  2015-10-14 15:11 Question about Haskell packages Paul van der Walt
@ 2015-10-14 17:19 ` Taylan Ulrich Bayırlı/Kammer
  0 siblings, 0 replies; 4+ messages in thread
From: Taylan Ulrich Bayırlı/Kammer @ 2015-10-14 17:19 UTC (permalink / raw)
  To: Paul van der Walt; +Cc: guix-devel

Paul van der Walt <paul@denknerd.org> 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question about Haskell packages
@ 2015-10-15 10:08 Federico Beffa
  0 siblings, 0 replies; 4+ messages in thread
From: Federico Beffa @ 2015-10-15 10:08 UTC (permalink / raw)
  To: Paul van der Walt; +Cc: Guix-devel

Paul van der Walt <paul@denknerd.org> writes:

[...]

> Ah, another question: do you people think it would be worthwhile /
> useful to provide a haskell-platform-$ver metapackage which depends on
> all the exact versions bundled in that HP?  See [1] for a list.

I think it's useful.

Regards,
Fede

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Question about Haskell packages
@ 2015-10-15 11:22 Federico Beffa
  0 siblings, 0 replies; 4+ messages in thread
From: Federico Beffa @ 2015-10-15 11:22 UTC (permalink / raw)
  To: Paul van der Walt; +Cc: Guix-devel

Paul van der Walt <paul@denknerd.org> writes:

> Hello Guix,
>
> 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.

The reason is likely that L1 needs one of its input at run time. If
another package declares L1 as its input, but not the library needed by
L1 at run-time, the latter will not be visible in the build environment
(only the declared packages plus some implicit inputs are visible) and
L1 will not be functional. In such a case the library needed at run-time
has to be declared as a propagated-input.

Regards,
Fede

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-10-15 11:22 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-14 15:11 Question about Haskell packages Paul van der Walt
2015-10-14 17:19 ` Taylan Ulrich Bayırlı/Kammer
  -- strict thread matches above, loose matches on Subject: below --
2015-10-15 10:08 Federico Beffa
2015-10-15 11:22 Federico Beffa

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.