Skip to Content.
Sympa Menu

sm-commit - Re: [SM-Commit] GIT changes to master grimoire by Lalo Martins (7509530c08c82b1120cb1cd7ac28581679948ae8)

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: Alexander Tsamutali <astsmtl AT gmail.com>(by way of Alexander Tsamutali <astsmtl AT gmail.com>)
  • To: "Lalo Martins" <lalo AT sourcemage.org>
  • Subject: Re: [SM-Commit] GIT changes to master grimoire by Lalo Martins (7509530c08c82b1120cb1cd7ac28581679948ae8)
  • Date: Sat, 27 Oct 2007 17:18:45 +0500
  • Resent-date: Sun, 28 Oct 2007 11:04:12 +0500
  • Resent-from: Alexander Tsamutali <astsmtl AT gmail.com>
  • Resent-to: sm-commit AT lists.ibiblio.org

В Sat, 27 Oct 2007 19:39:50 +0800
"Lalo Martins" <lalo AT sourcemage.org> пишет:

> > And third, I don't think that ghc-bin from
> > z-rejected should affect out main grimoire so badly.
>
> I would agree in principle with the z-rejected thing, but in this
> case, as you said, I don't see why I would *ever* care to spend a
> whole night compiling ghc, if I have ghc-bin and zero interest in
> haskell :-) So I think ghc-bin is an important convenience spell for,
> eg, Telepathy developers who need to have darcs.

I think there is another option. I've found on the ghc wiki that
compile time can be greatly reduced by disabling optimisations. They
say that time goes down to minutes compared to hours needed for
optimised build. We can add option to ghc spell to disable
optimisations. What you think about it?

> > That said, i think we need to change GHC dependencies to ghc and
> > leave ghc-bin conflicting with ghc until a better solution is
> > found. Any objections?
>
> Well... yeah :-) that would make darcs uncastable for me again,
> unless you go and fix darcs (and any other haskell spells we have).
> And then, as you also mentioned, you'd need to be watching all
> releases of ghc-bin to know which libraries are installed, and fix
> deps accordingly.

I think you misread it. I proposed to change all spells that depend on
GHC to depend on ghc (only on ghc, not ghc-bin). Then everything will
work until we decide something on ghc-bin.

> Here's a third alternative -- and for this one I may even be willing
> to help. How about changing the ghc-bin spell to install exactly the
> same things as ghc? Ok, it downloads the libs (they're part of the
> tarball), but they don't get installed, so the two spells are
> functionally equivalent.

I think this is possible. The only problem (aside from hacking
installation procedure) i see is package.conf (a.k.a
pain_in_my_ass.conf). This file has some intermediate format, it's
text, but not human readable/editable (probably serialised haskell
data). There is a tool to manage this file called ghc-pkg. To delete
package you need corresponding .cabal file and ghc-bin tarball doesn't
provide us these, although we can try and find them.


P.S. This message isn't addressed to ML as well as yours. You did it
on purpose? If not we can forward our messages to ML so that everyone
can participate in discussion.

--
Alexander Tsamutali




Archive powered by MHonArc 2.6.24.

Top of Page