Cabal Release Candidate

[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.

  $ 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 at haskell.org and
>> Isaac Jones: ijones at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries