ANNOUNCE: GHC 7.4.1 Release Candidate 2

[Evan Laforge]

>> I downloaded the latest cabal-install from
>> http://hackage.haskell.org/package/cabal-install and that was a
>> mistake right off.
>
> Assuming you upgraded, you probably had an old version of
> cabal-install. You should be able to keep using it for the time being.
> The cabal binary picks up the GHC that's currently in path (or the one
> you explicitly specify via --with-ghc). There's no requirement to use
> it with the GHC version that it has been built with.

In fact it's a new install from scratch, no previous ghc.  I didn't
see why I should install a bunch of stuff I didn't plan on using (I do
main development on another machine), but maybe I should have
installed the platform first, and then replaced the ghc.

>> After fiddling around I figured out I apparently
>> need the one bundled with ghc... and sure enough, the source version
>> has a cabal-install-0.13.3.
>
> The current development version is indeed at 0.13.3, but since it's in
> development, your copy might or might not have the latest patches. The
> definitive darcs repository for both Cabal and cabal-install is at:
>
>  darcs get http://darcs.haskell.org/cabal/

Ah, I'll give that a try as soon as I get back home.

>> And how are other people testing this out
>> if cabal-install has out of date dependencies?  And strangest, why is
>> the 'base' dependency so old?
>
> That's a consequence of how Cabal tries to resolve dependencies. There
> are multiple flags in the .cabal file (to allow it to build with older
> or strange configurations), and once the default flag settings fail,
> Cabal will automatically try other assignments. If all assignments
> fail, it will complain about the missing dependencies for the flag
> assignment it tried last. So there isn't really a dependency on such
> an old version of base.

Thanks for the explanation.  I'd seen this kind of behaviour from
cabal before, and noted that the constraint does exist under certain
flags, but didn't understand how it would choose a particular flag if
I didn't pass it.

>> And while I'm wondering about cabal, why on earth is it that so many
>> Setup.hs files are actually Setup.lhs and with no actual literate
>> contents?
>
> Does it really matter?

It's not of great importance.  But it means the Setup names are
unpredictable so using shell history tends to fail, I have to remember
to complete with tab and not automatically type "Setup.hs", simple
shell functions tend to break, etc.  I was more curious about how it
happens so much in the first place.  My best guess is that someone at
the very beginning had an "everything lhs" style, and then most people
simply copy another project's Setup, so it's a sort of founder's
effect.  To be honest it probably mostly piques my sense of tidiness.

On Wed, Feb 1, 2012 at 8:16 AM, Simon Hengel <sol at typeful.net> wrote:
> Are you referring to the classical pattern, that allows you to add a
> shebang?
>
>    #!/usr/bin/env runhaskell
>
>    > import Distribution.Simple
>    > main = defaultMain

Ohh, so it's a trick to allow #! in there... I guess that would
explain it!  I just type runghc on everything and it seems like a lot
of those don't have the executable bit set, so I hadn't thought of
that reason.