
I just discovered a problem. In GHC > 6.4, local modules take precedence over package modules. This causes a problem for the Cabal distribution, eg: $ ghc-6.4.1 Setup.lhs --make -o setup Chasing modules from: Setup.lhs ./Distribution/Simple.hs:61:1: lexical error ie. it picks up Distribution.Simple from the local copy rather than the installed version. The solution is simple, if a little inconvenient: the Cabal sources have to move into a subdirectory of the distribution. $ mkdir src $ mv Distribution Language src/ and add "hs-source-dir: src" to Cabal.cabal. I can't see another way around it; the new GHC behaviour is definitely better than before (it was requested by several people). This problem only affects Cabal. Cheers, Simon On 14 July 2005 14:45, Simon Marlow wrote:
Seems to install and work on the simple test I tried.
A typo in the README:
$ ghc-pkg describe Cabal-1.0 | ghc-pkg --user regiser -
s/regiser/register/
I think we should separate the instructions for installing a new Cabal into "root access" and "no root access" (and say something Windows-compatible too, like "Administrator access").
When I installed the new Cabal globally (onto GHC 6.4), the old one was hidden automatically, so the suggestion for unregistering the old one in the README is unecessary. However, when installing the new one with --user, you definitely *do* need to do this:
$ ghc-pkg describe Cabal-1.0 | ghc-pkg --user register - $ ghc-pkg --user hide Cabal-1.0
but you should do it *before* installing Cabal-1.1.1 (otherwise a different sequence is required... sigh).
So to summarise:
- to install globally / with root access: should "just work"
- to install just for me: copy+hide Cabal-1.0, then install the new one with --user.
I should really do something about this for 6.4.1. Everything seems a bit adhoc, though. Perhaps: in the absence of any package flags to the contrary, GHC could default to hiding all but the newest version of packages which have more than one version exposed?
Cheers, Simon
On 14 July 2005 07:52, Isaac Jones wrote:
I've updated the web page to have 1.0 (as Malcolm requested), and added 1.1.1, which is a "release candidate" for 1.2. Please forgive me for going insane with the version numbers.
I'd appreciate it if early adopter types try out 1.1.1. In particular, check out the README wrt installing alongside-of or instead-of 1.0 with ghc 6.4.
BTW, if anyone loves to manage releases and would like to relieve me of this duty so I can spend my time fixing bugs and adding features, just let me know ;)
peace,
isaac
--------------------------------------------------------------- The Haskell Cabal The Common Architecture for Building Applications and Libraries. http://www.haskell.org/cabal
IMPORTANT INFORMATION:
See both the README file and the changelog for important interface changes and installation instructions.
DOWNLOAD:
The Haskell Cabal has reached version 1.1.1. This pre-release has a number of new features including a hook for testing, support for profiling, and support for _stub files, as well as several bug fixes.
Download the Cabal here (source and debian versions available): http://www.haskell.org/cabal/download.html
BUGS:
Please report bugs and wish-list items to libraries@haskell.org and Isaac Jones: ijones@syntaxpolice.org.
ABOUT:
The Haskell Cabal is meant to be a part of a larger infrastructure for distributing, organizing, and cataloging Haskell Libraries and Tools. It is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community.
Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must to do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages.
The Cabal is only one contribution to the larger goal. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on.
NOTES:
You cannot currently execute most setup scripts with "./Setup.lhs" since most systems do not have a runHaskell executable installed. You can compile it with ghc thusly: "ghc -package Cabal Setup.lhs -o setup" and then use the "setup" executable after that.
This release is meant to provide the community with concrete information about how the interfaces are shaping up. This release does NOT fix the interfaces, we can't promise not to break anything that relies on these interfaces. We hope that Haskell authors will try to package their software using these tools, and let us know where they fall short.
MORE INFORMATION:
Please see the web site for the source code, interfaces, and especially the proposal, which will serve as documentation for this release:
http://www.haskell.org/cabal/ _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

"Simon Marlow"
I just discovered a problem. In GHC > 6.4, local modules take precedence over package modules. This causes a problem for the Cabal distribution, eg:
$ ghc-6.4.1 Setup.lhs --make -o setup Chasing modules from: Setup.lhs ./Distribution/Simple.hs:61:1: lexical error
ie. it picks up Distribution.Simple from the local copy rather than the installed version. The solution is simple, if a little inconvenient: the Cabal sources have to move into a subdirectory of the distribution.
It's supposed to do this; use "make setup" (which just passes -cpp to ghc) to create the setup file. It bootstraps itself, but I could move the sources into a subdirectory anyway to make it possible to build it either way. I don't have makefile targets for hugs or nhc, so that would be good. peace, isaac
participants (2)
-
Isaac Jones
-
Simon Marlow