- cabal-devel - Haskell.org

[Hackage] #632: After updating cabal-install Zlib incompatible version
by Hackage 07 Mar '10

07 Mar '10

#632: After updating cabal-install Zlib incompatible version ---------------------------------+------------------------------------------ Reporter: captainCrash | Owner: Type: defect | Status: new Priority: high | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: major | Keywords: Difficulty: unknown | Ghcversion: Platform: Mac OS | ---------------------------------+------------------------------------------ When I ran cabal update it suggested that I had to update cabal-install. Which I did. Then running cabal update again gave the error: > cabal update Downloading the latest package list from hackage.haskell.org cabal: Codec.Compression.Zlib: incompatible zlib version Any other action requiring ZLib also fails. I downloaded a new version of cabal itself, untarred it, and cabal installed it. The problem still exists. I run ZLib version 0.5.2.0. I have GHC version 6.10.3. And run this all on Mac OS X 10.6.3 -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/632> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #633: Cabal-1.8.0.2 fails to build packages for hugs: --inplace is not supported with Hugs
by Hackage 07 Mar '10

07 Mar '10

#633: Cabal-1.8.0.2 fails to build packages for hugs: --inplace is not supported with Hugs ----------------------------+----------------------------------------------- Reporter: nomeata | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- For the Debian packages, we use Cabal to build packages for ghc6 and for hugs. Unfortunately, with Cabal-1.8, the hugs support is broken: {{{ debian/hlibrary.setup configure --hugs --prefix=/usr -v2 --builddir=dist- hugs Configuring binary-0.5.0.2... Flags chosen: applicative-in-base=True, split-base=True, bytestring-in-base=True Dependency array -any: using array Dependency base >1 && <1: using base Dependency containers -any: using containers Using Cabal-1.8.0.2 compiled by ghc-6.12 Using compiler: hugs Using install prefix: /usr Binaries installed in: /usr/bin Libraries installed in: /usr/lib/hugs/packages/binary Private binaries installed in: /usr/libexec Data files installed in: /usr/share/binary-0.5.0.2 Documentation installed in: /usr/share/doc/binary-0.5.0.2 No alex found Using ar found on system at: /usr/bin/ar No c2hs found Using cpphs version 1.9 found on system at: /usr/bin/cpphs Using ffihugs found on system at: /usr/bin/ffihugs Using gcc version 4.4.3 found on system at: /usr/bin/gcc Using ghc version 6.12.1 found on system at: /usr/bin/ghc Using ghc-pkg version 6.12.1 found on system at: /usr/bin/ghc-pkg No greencard found Using haddock version 2.6.0 found on system at: /usr/bin/haddock No happy found No hmake found Using hsc2hs version 0.67 found on system at: /usr/bin/hsc2hs Using hscolour version 1.15 found on system at: /usr/bin/HsColour Using hugs found on system at: /usr/bin/hugs No jhc found Using ld found on system at: /usr/bin/ld No lhc found No lhc-pkg found No nhc98 found No pkg-config found Using ranlib found on system at: /usr/bin/ranlib Using strip found on system at: /usr/bin/strip Using tar found on system at: /bin/tar debian/hlibrary.setup build --builddir=dist-hugs Preprocessing library binary-0.5.0.2... Building binary-0.5.0.2... Registering binary-0.5.0.2... hlibrary.setup: --inplace is not supported with Hugs }}} The reason seems to be the build function in ./Distribution/Simple/Build.hs: {{{ build pkg_descr lbi flags suffixes = do let distPref = fromFlag (buildDistPref flags) verbosity = fromFlag (buildVerbosity flags) initialBuildSteps distPref pkg_descr lbi verbosity suffixes setupMessage verbosity "Building" (packageId pkg_descr) internalPackageDB <- createInternalPackageDB distPref withLibLBI pkg_descr lbi $ \lib clbi -> do info verbosity "Building library..." buildLib verbosity pkg_descr lbi lib clbi installedPkgInfo <- generateRegistrationInfo verbosity pkg_descr lib lbi clbi True{-inplace-} distPref -- Register the library in-place, so exes can depend -- on internally defined libraries. registerPackage verbosity installedPkgInfo pkg_descr lbi True{-inplace-} internalPackageDB -- Use the internal package db for the exes. let lbi' = lbi { withPackageDB = withPackageDB lbi ++ [internalPackageDB] } withExeLBI pkg_descr lbi' $ \exe clbi -> do info verbosity $ "Building executable " ++ exeName exe ++ "..." buildExe verbosity pkg_descr lbi' exe clbi }}} Here, the inplace flag is unconditionally set to true. But in ./Distribution/Simple/Register.hs, we have {{{ registerPackageHugs verbosity installedPkgInfo pkg lbi inplace _packageDb = do when inplace $ die "--inplace is not supported with Hugs" let installDirs = absoluteInstallDirs pkg lbi NoCopyDest createDirectoryIfMissingVerbose verbosity True (libdir installDirs) writeUTF8File (libdir installDirs </> "package.conf") (showInstalledPackageInfo installedPkgInfo) }}} I’d be grateful for a quick work-around or patch, as this is holding up the transition to ghc 6.12 in Debian. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/633> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

Cabal bugs on Windows
by Neil Mitchell 06 Mar '10

06 Mar '10

Hi, I get this error on multiple machines running Windows, with both GHC 6.10.4 and 6.12.1: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 $ cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library $ cabal update Downloading the latest package list from hackage.haskell.org cabal: Codec.Compression.Zlib: premature end of compressed stream This is the same error as reported on http://hackage.haskell.org/trac/hackage/ticket/636. I'm also not the only Windows user I know who has got this. Is Cabal broken in some way? It's fairly serious and annoying that GHC 6.12.1 can't be used with Cabal. Thanks, Neil

1 1

[Hackage] #517: make cabal install command support haddock options
by Hackage 02 Mar '10

02 Mar '10

#517: make cabal install command support haddock options ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Currently the `cabal install` command supports just `--enable- documentation` which turns on library docs. The `cabal haddock` option has various other things like enabling docs for executables, specifying css files, linking to source code etc. Some or perhaps all of these would be useful when installing packages. This is not fundamentally difficult. The task is just to work out which options are useful (or perhaps all) and how to present the user interface (command line options and config file). Bonus points for a UI that is usable and orthogonal. See #206 for some of the previous discussion on this topic. See also #516 about maintaining a central haddock module index. For reference the current haddock command options are: {{{ Flags for haddock: -h --help Show this help text -v --verbose[=n] Control verbosity (n is 0--3, default verbosity level is 1) --builddir=DIR The directory where Cabal puts generated build files (default dist) --hoogle Generate a hoogle database --html-location=URL Location of HTML documentation for pre- requisite packages --executables Run haddock for Executables targets --internal Run haddock for internal modules and include all symbols --css=PATH Use PATH as the haddock stylesheet --hyperlink-source Hyperlink the documentation to the source code (using HsColour) --hscolour-css=PATH Use PATH as the HsColour stylesheet --with-haddock=PATH give the path to haddock --haddock-options=OPTS give extra options to haddock --haddock-option=OPT give an extra option to haddock (no need to quote options containing spaces) }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/517> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 9

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 28 Feb '10

28 Feb '10

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn@… | Owner: blackh Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ---------------------------------+------------------------------------------ Comment(by guest): I've made a patch implementing the hack I outlined in the previous comment (which works for me): http://code.haskell.org/~aavogt/cabal-1.8-dev/hack-to-correct-build- failure-with-ghc_6_12_1-_issue-89__.dpatch or, darcs pull http://code.haskell.org/~aavogt/cabal-1.8-dev -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:27> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 28 Feb '10

28 Feb '10

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn@… | Owner: blackh Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ---------------------------------+------------------------------------------ Changes (by guest): * cc: vogt.adam@… (added) Comment: Trying to build the example (using Setup.hs): cabal/tests/PackageTests/BuildDeps/InternalLibrary1 Ends up passing to ghc: {{{-package-id InternalLibrary1-0.1}}} Failing with: {{{<command line>: cannot satisfy -package-id InternalLibrary1-0.1}}} Looks like Cabal should pass -package, or find the full hash for {{{InternalLibrary1}}} I'm on ghc-6.12.1, Cabal-1.8.0.2 Adam Vogt -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:26> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Building/installing OS X application bundles for GUIs - cabal-macosx
by Andy Gimblett 24 Feb '10

24 Feb '10

Hi all, Last week I quietly released v0.1.0 of cabal-macosx, providing support for building OSX application bundles (e.g. and in particular for GUIs created using wxHaskell and gtk2hs - hence all the cross-posting): http://hackage.haskell.org/package/cabal-macosx I'm now soliciting input on how to handle the install stage, leading (I hope) to a loudly-announcable release soon. :-) The current package provides a post-build hook which creates an application bundle at dist/build/foo.app (for example). It seems to work well. See the source repository for examples. However, running "runghc Setup install" copies the bare executable at dist/build/foo/foo (rather than the foo.app bundle) to the install location, which is no good. So I need to put in some install infrastructure to copy the .app, not the bare executable, to the right place. That raises the question: what is the right place? It seems to me that the defaults are not the right defaults for this case. --global should probably go to /Applications, and --user should perhaps go to ~/ Applications (though I'm less sure about that). Of course, end-users can explicitly set this on a per-install basis, but it seems that for bundles we'd want to override the default. Thus I'm currently asking: * What do people think about the default installation question? * Can anyone advise me on the right way to handle this (installing the .app, and overriding the default locations) with Cabal? I'm hoping I can just tweak part of the LocalBuildInfo and let the default machinery then handle the work, but at present it's not clear to me how to do that, and rather than spend ages trying to figure it out, perhaps someone who knows can help me out? I'm hoping I'm not going to have to completely override the install machinery - that would feel somewhat self-defeating. Many thanks, -Andy -- Andy Gimblett http://gimbo.org.uk/

1 0

[Hackage] #637: Allow overriding defaultPackageDesc
by Hackage 19 Feb '10

19 Feb '10

#637: Allow overriding defaultPackageDesc ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I'm trying to keep the source of multiple packages in a single source repository. Unfortunately, I cannot maintain a .cabal file per package, because some commands invoke function defaultPackageDesc unconditionally. I tried using {{{defaultMainNoRead}}} instead of {{{defaultMain}}} and passing the desired package name through the environment. This solution doesn't work at all in 1.6.0.3. It works only partially in HEAD: {{{Setup configure}}} and {{{Setup build}}} work but {{{Setup sdist}}} does not because it ignores the {{{readDesc}}} field and invokes {{{defaultPackageDesc}}} unconditionally. Would it be possible to add a field to {{{UserHooks}}} which would specify the .cabal filename to use? Then {{{defaultPackageDesc}}} should be always called through this field, never directly, and could thus be consistently overridden. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/637> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #631: readline-1.0.1.0 not linking with GNU macports readline on darwin
by Hackage 09 Feb '10

09 Feb '10

#631: readline-1.0.1.0 not linking with GNU macports readline on darwin ----------------------------------+----------------------------------------- Reporter: osaunders | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.10.1 Platform: Mac OS | ----------------------------------+----------------------------------------- I had some problems installing readline-1.0.1.0 on Darwin. I don't think it was looking for GNU readline among my Macports. In the end I did this and it worked: sudo cabal unpack readline cd readline-1.0.1.0/ chmod +x configure sudo ./configure --with-readline-includes=/opt/local/include/readline --with-readline-libraries=/opt/local/lib sudo runhaskell Setup build sudo runhaskell Setup install -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/631> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 07 Feb '10

07 Feb '10

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn@… | Owner: blackh Type: enhancement | Status: assigned Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.4.2 Platform: Linux | ---------------------------------+------------------------------------------ Comment(by AnttiJuhaniKaijanaho): Replying to [comment:24 duncan]: > Replying to [comment:23 AnttiJuhaniKaijanaho]: > I'm concerned that cabal makes simple things more complicated than they need to be. > > Just to note, this is not a model we ever intend to support in the "Simple" build system. Build systems should be purely functional. I don't see how sharing build results would break pure functionality. > > ... Heh. Should I be opening a separate ticket? :) > > Probably. A common section is not a bad thing. Note that this would not give any sharing of build results. It's just a shortcut to putting the same options in each section. Opened as #630. (I reiterate: not sharing of build results is ugly. There is a passable argument against it in the genreal case, but in simple cases its lack just gives me another reason to NOT use Cabal when I can get away with it.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:25> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0