Cabal Release Candidate
simonmar at microsoft.com
Thu Jul 14 10:39:17 EDT 2005
I just discovered a problem. In GHC > 6.4, local modules take
precedence over package modules. This causes a problem for the Cabal
$ 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.
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 -
> 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?
> 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 ;)
>> The Haskell Cabal
>> The Common Architecture for Building Applications and Libraries.
>> IMPORTANT INFORMATION:
>> See both the README file and the changelog for important interface
>> changes and installation instructions.
>> 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):
>> Please report bugs and wish-list items to libraries at haskell.org and
>> Isaac Jones: ijones at syntaxpolice.org.
>> 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.
>> 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
>> Libraries mailing list
>> Libraries at haskell.org
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries