Cabal, System.Filepath
To my surprise, if you type ^C at the right moment you can trash GHC's (system-wide) package list. I figured it was easier to reinstall than fix, but forgot Debian installs GHC 6.6 if I don't ask for "unstable". So, let's get Cabal on its feet again: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6 $ darcs pull Pulling from "http://darcs.haskell.org/cabal"... No remote changes to pull in! $ ghc -i. --make Setup.lhs -o setup Distribution/Simple.hs:114:7: Could not find module `System.FilePath': Use -v to see a list of the files searched for. Can I humbly suggest that Cabal rely on very few external libraries? (I'm switching to 6.6.1 as I type this.) cheers peter
On Thu, 2007-12-06 at 17:35 +0700, Peter Gammie wrote:
To my surprise, if you type ^C at the right moment you can trash GHC's (system-wide) package list. I figured it was easier to reinstall than fix, but forgot Debian installs GHC 6.6 if I don't ask for "unstable". So, let's get Cabal on its feet again:
Debian actually installs a backup of the global package.conf file. It's called package.conf.shipped or something like that.
$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6
$ darcs pull Pulling from "http://darcs.haskell.org/cabal"... No remote changes to pull in!
$ ghc -i. --make Setup.lhs -o setup
Distribution/Simple.hs:114:7: Could not find module `System.FilePath': Use -v to see a list of the files searched for.
Can I humbly suggest that Cabal rely on very few external libraries?
We recently defined filepath to be a core library. As you point out however this does pose a problem for older compilers. Fortunately it's not that bad, you can build and install filepath using the older cabal that comes with your older compiler. If that's not possible for whatever reason you can download both Cabal and filepath and: ghc -i../filepath --make Setup.lhs -o setup Duncan
On 06/12/2007, at 6:56 PM, Duncan Coutts wrote:
On Thu, 2007-12-06 at 17:35 +0700, Peter Gammie wrote:
Can I humbly suggest that Cabal rely on very few external libraries?
We recently defined filepath to be a core library. As you point out however this does pose a problem for older compilers. Fortunately it's not that bad, you can build and install filepath using the older cabal that comes with your older compiler. If that's not possible for whatever reason you can download both Cabal and filepath and:
ghc -i../filepath --make Setup.lhs -o setup
I realise all this, I just wanted to log the fact that darcs-Cabal does not build on GHC 6.6. I thought it was a design goal for Cabal to compile on all GHCs back to 6.4.x (or something). No matter, I installed GHC 6.6.1: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6.1 Next problem: let's reinstall the 'cgi' package (latest from darcs): $ ghc-pkg list /usr/lib/ghc-6.6.1/package.conf: Cabal-1.1.6.2, Cabal-1.3.1, base-2.1.1, filepath-1.0, (ghc-6.6.1), haskell98-1.0, parsec-2.0, readline-1.0, regex-base-0.72, regex-compat-0.71, regex-posix-0.71, rts-1.0, stm-2.0, template-haskell-2.1, unix-2.1 /home/peteg/.ghc/i386-linux-6.6.1/package.conf: mtl-1.1.0.0, network-2.1.0.0, xhtml-3000.0.2.1 Note that I've installed the dependencies in my home directory. $ runghc Setup.*hs configure --prefix=$HOME -v3 Configuring cgi-3001.1.5.1... Creating dist (and its parents) /usr/bin/ghc --numeric-version looking for package tool: ghc-pkg near compiler in /usr/bin found package tool in /usr/bin/ghc-pkg /usr/bin/ghc-pkg --version /usr/bin/ghc -c /tmp/tmp19799.c -o /tmp/tmp19799.o /usr/bin/ld -x -r /tmp/tmp19799.o -o /tmp/tmp19800.o Reading installed packages... /usr/bin/ghc-pkg --global list Setup.hs: At least the following dependencies are missing: network >=2.0, mtl >=1.0, xhtml >=3000.0.0 Why is ghc-pkg looking only at globally-installed packages? cheers peter
On Thu, 2007-12-06 at 21:44 +0700, Peter Gammie wrote:
On 06/12/2007, at 6:56 PM, Duncan Coutts wrote:
On Thu, 2007-12-06 at 17:35 +0700, Peter Gammie wrote:
Can I humbly suggest that Cabal rely on very few external libraries?
We recently defined filepath to be a core library. As you point out however this does pose a problem for older compilers. Fortunately it's not that bad, you can build and install filepath using the older cabal that comes with your older compiler. If that's not possible for whatever reason you can download both Cabal and filepath and:
ghc -i../filepath --make Setup.lhs -o setup
I realise all this, I just wanted to log the fact that darcs-Cabal does not build on GHC 6.6. I thought it was a design goal for Cabal to compile on all GHCs back to 6.4.x (or something).
I have considered bundling filepath for exactly this reason. I'm still undecided.
Why is ghc-pkg looking only at globally-installed packages?
It's not ghc-pkg, it's Cabal that by default only looks at the global packages. You can configure with --user to have it look at the user ones. Personally I'm in favour of switching the default to --user. Of course it cannot use user packages and then install globally, and the current default prefix is /usr/local which is usually root only, so if we switch the default to user installs then we'd have to switch the default prefix. I'd prefer that too though. However it's a change that would require general consensus. Duncan
On 07/12/2007, at 5:40 AM, Duncan Coutts wrote:
On Thu, 2007-12-06 at 21:44 +0700, Peter Gammie wrote:
Why is ghc-pkg looking only at globally-installed packages?
It's not ghc-pkg, it's Cabal that by default only looks at the global packages. You can configure with --user to have it look at the user ones. Personally I'm in favour of switching the default to --user.
Of course it cannot use user packages and then install globally, and the current default prefix is /usr/local which is usually root only, so if we switch the default to user installs then we'd have to switch the default prefix. I'd prefer that too though. However it's a change that would require general consensus.
Ah, I see. I didn't realise configure had a --user switch as well. A stop-gap might be to generate a more helpful error message: ghc-pkg --global list <check for deps> if unsatisfied dep ghc-pkg list if dep is satisfied now, print "Perhaps configure with --user?" IMH and not so informed opinion, I think the defaults should be close to autoconf's, if only by the principle of least surprise. Thanks! cheers peter
participants (2)
-
Duncan Coutts -
Peter Gammie