[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libghc-cabal-dev provided by GHC



On Sat, 04 Oct 2014 00:58:01 +0200
Joachim Breitner <nomeata@debian.org> wrote:

> Hi,
> 
> 
> Am Freitag, den 03.10.2014, 19:57 +0200 schrieb Sven Bartscher:
> > A while ago the cabal library was packaged separately from GHC, but
> > since I didn't follow the discussion very closely, I don't know the
> > details of the process.
> > 
> > As it's now, we have two version of the cabal library in the
> > repository. (The libghc-cabal-dev one and the GHC  one).
> > 
> > Most of the time it's not that much of a problem, but sometimes it
> > gets really annoying (i.e. incompatibilities between cabal-install and
> > Setup.hs that imports functions compiled against the GHC version...) .
> > 
> > Is cabal going to be removed from GHC, or are there any big problems
> > coming with that?
> 
> we haven’t fully explored all possibilities and problems yet. I suggest
> to use cabal as shipped by GHC as long as possible, and only depend on
> libghc-cabal-dev if explicitly required as a dependency (cabal-install
> being the prime motivation).
> 
> Why exactly is your proposed changes to hgettext required?

hgettext ships some cabal functions. Most notably gettextDefaultMain,
which replaces the original defaultMain (from cabal) and installs
the .po files and other stuff that belongs to gettext.

If that function is compiled against the old GHC version, running cabal
install on a package that uses this function result in errors, because
of invalid command line flags. I guess this is because Setup.hs has
changed it's CLI in the newer version, but cabal-install expects this
new CLI. (Running runghc Setup.hs <command> works fine, since the newer
cabal-install isn't involved)

This means most packages, that ship functions that are to be used in
Setup.hs, should be compiled against the same version as cabal-install.
To ensure compatibility.

Regards
Sven

Attachment: signature.asc
Description: PGP signature


Reply to: