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>
  • To: sm-commit AT lists.ibiblio.org
  • Subject: Re: [SM-Commit] GIT changes to master grimoire by Lalo Martins (7509530c08c82b1120cb1cd7ac28581679948ae8)
  • Date: Sun, 28 Oct 2007 12:40:12 +0500

В Sun, 28 Oct 2007 09:38:54 +0800
"Lalo Martins" <lalo AT sourcemage.org> пишет:

> On 10/27/07, Alexander Tsamutali <astsmtl AT gmail.com> wrote:
> > В Sat, 27 Oct 2007 19:39:50 +0800
> > 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 would be welcome, but as you say, I still need to download 40M of
> ghc-bin to compile ghc. For me it's hardly worth it.

If we can reduce compile time to minutes, and the resulting compiler
will be reasonably fast, then you wouldn't notice much difference
between casting ghc-bin and ghc.

> > > 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.
>
> Last time I tried to cast ghc (admittedly it was a long time ago) it
> failed. I'm on x86_64. And ghc doesn't use ccache, so even if the
> problem is easy to fix, each attempt consumes an entire night. So...
> not being able to use ghc-bin would be equivalent to being uncastable
> for me. I'd end up installing it manually instead of using sorcery.

Once again, if compile time will be reduced you can try and check it,
and if something goes wrong - fix it. And I'll do my best to help you.

> > > 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.
>
> Well. The simple alternative, again, is to live it as it is now; I
> can assure you, installing the libraries on top of ghc-bin doesn't
> cause any problems. Redundant? Yeah, but doesn't break anything.

Not even close to the Right Way. :-)

> > 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.
>
> Actually, your second message to me wasn't addressed to the ML, so I
> followed standard netiquette and replied privately as well :-) I have
> no objection to forwarding the discussion there.

Sorry. That was really my fault and i didn't noticed it. :-/ Please
forward your messages to ML.

--
Alexander Tsamutali




Archive powered by MHonArc 2.6.24.

Top of Page