[gobolinux-users] Haskell Cabal build type?

[Michael Homer]

On 7/16/07, Isaac Dupree <isaacdupree at charter.net> wrote:
>
> New versions of Happy and Alex require Cabal (The Haskell Cabal: Common
> Architecture for Building Applications and Libraries,
> <http://haskell.org/cabal/>) instead of 'configure'-type build. (and I
> need those new versions in order to develop GHC HEAD)  More applications
> written in Haskell are likely to use this in the future.  That's not so
> bad if we can just make a new recipe type.
>
> Common Haskell libraries are being split up into separate pieces and
> less offered installed with newer releases of the GHC compiler.  We
> don't want to flood the /Programs namespace with all different little
> Haskell libraries; and each Cabal-based program-or-library declares
> which packages/modules/libraries it depends on, in a standard .cabal
> file.  We shouldn't try to manually keep intra-Haskell dependency
> listings in sync with these, either, as they are likely to change
> frequently.  Given how GHC normally works, it puts these in a system
> shared directory named by the GHC version (since e.g. GHC 6.6 and GHC
> 6.6.1 -generated binaries are incompatible with each other).  So if an
> installed /Programs/GHC/6.6.1/ is used, should the libraries be
> installed somewhere inside /Programs/GHC/6.6.1/ perhaps?
Why can't they just go in /P/Foo/Current/lib/haskell/ghc-6.6.1/, and
GHC be configured to look in /S/L/L/haskell/ghc-<ver>? That's how
Perl, Ruby, and Python work now.
> I'm thinking Perl modules may be a similar existing issue; are they handled well, and
> if so, how?
Perl modules work as described, and are named in the form
"Perl-XML-Parser" for CPAN's XML::Parser. There's a perl recipe type
that they use to handle the configure.pl-style compilation.

I think if you add a haskell recipe type that deals with things
appropriately that should be fine. Naming them the same way as Perl
modules should be ok too, unless it's expected that there'll be
hundreds of them (and even then...). They certainly shouldn't install
into GHC's directory unless it's unavoidable.

I think the standard Resources/Dependencies system should be used as
well, possibly with a script to convert from the original format.
Breaking the dependencies system for one class of programs isn't
really a good idea and will lead to inconsistent behaviour.
-Michael