<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><tt>I'll be compiling it myself anyway
        but with this patch added:<br>
        &nbsp; <a class="moz-txt-link-freetext" href="http://hackage.haskell.org/trac/ghc/ticket/3858">http://hackage.haskell.org/trac/ghc/ticket/3858</a><br>
        ... if there is an interest having the patch there.<br>
        <br>
        I'm typically adding two more patches (but I can skip these for
        you if you<br>
        do not like it):<br>
        * add "breakTick" id to break point list and the information
        about ignored<br>
        &nbsp; breakpoint; this is interesting when you want to find out
        which <br>
        &nbsp; breakpoint was ignored; it is very dirty workaround for<br>
        &nbsp; <a class="moz-txt-link-freetext" href="http://hackage.haskell.org/trac/ghc/ticket/2950">http://hackage.haskell.org/trac/ghc/ticket/2950</a><br>
        &nbsp; I did not have time to do a proper patch.<br>
        * I'm adding 0.1s delay when printing ghci prompt. Another dirty
        way to get<br>
        &nbsp; proper interleaving of stderr/stdout when stderr is coloured
        using<br>
        &nbsp; something like <a class="moz-txt-link-freetext" href="http://www.hck.sk/users/peter/pub/colorize.c">http://www.hck.sk/users/peter/pub/colorize.c</a><br>
        &nbsp; I use it to get all stderr in red (stdout is default black),
        and still<br>
        &nbsp; achieve proper interleaving of stderr text with stdout text.<br>
        &nbsp; It is quite possible this patch is not needed any more but it
        was needed<br>
        &nbsp; when haskeline was introduced the first time. I do not know
        why, ghci was<br>
        &nbsp; the only thing which showed any issues.<br>
        <br>
        I have 16GiB, so if the only problem is the memory, then I'll be
        quick.<br>
        <br>
        Otherwise, I do not mind if you use ghc from [extra]. There is
        no special<br>
        &nbsp;reason not to use [extra] version except extra maintainers can
        break<br>
        &nbsp;our dependencies if they do unexpected recompile probably with
        some<br>
        &nbsp;significant patches. Although every recompile can break
        dependencies,<br>
        &nbsp;mostly it does not happen.<br>
        You can just place copy of the [extra] version in [haskell] and
        there<br>
        &nbsp;should not be any problem at all since you would be in charge
        of any<br>
        &nbsp;ghc update. We would mirror only the ghc package in [haskell].<br>
        <br>
        Peter.<br>
      </tt><br>
      <br>
      On 06/15/2012 09:54 PM, Magnus Therning wrote:<br>
    </div>
    <blockquote cite="mid:20120615195431.GA16404@ohann" type="cite">
      <pre wrap="">I've been working on upgrading [haskell] to Ghc 7.4.2 for a few days
now.  So far no luck :(

The build always fails on creating documentation.  Yesterday I
resorted to taking the source package from [extra], which is known to
build fine... but still it failed on generating the docs.  I now
suspect this is due to the limited memory available on the machine I
use to build (1.5GB).

For the moment I've given up on building Ghc especially for use in
[haskell].  In order to move on I'll instead make use of Ghc out of
[extra].  If anyone has any objections to that, then please speak up.

/M

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
arch-haskell mailing list
<a class="moz-txt-link-abbreviated" href="mailto:arch-haskell@haskell.org">arch-haskell@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://www.haskell.org/mailman/listinfo/arch-haskell">http://www.haskell.org/mailman/listinfo/arch-haskell</a>
</pre>
    </blockquote>
    <br>
    <br>
  </body>
</html>