February 2010 - cabal-devel

[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 27 Feb '10

27 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 18 Feb '10

18 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

[Hackage] #630: Please add support for common modules and options
by Hackage 07 Feb '10

07 Feb '10

#630: Please add support for common modules and options -----------------------------------+---------------------------------------- Reporter: AnttiJuhaniKaijanaho | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal specification | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | -----------------------------------+---------------------------------------- In some packages I have many executables that share modules and/or compilation options but I have no need for a library. In such a case it would be useful to be able to specify modules and compilation options that are common to all executables in the package. See the discussion in #89 for more context. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/630> 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 duncan): Replying to [comment:23 AnttiJuhaniKaijanaho]: > Replying to [comment:22 duncan]: > > For ghc --make you simply get wrong results (it does not track when you change compile options). > > Which is relevant in sophisticated cases. 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. The one concession we will need to make to a purely functional description is the ability to specify exceptions that some changed input will not trigger another function to be recalculated (eg while hacking, temporarily specifying that stage1 of a compiler changing will not cause rebuild of stage2). > ... 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. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:24> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #629: cabal-install getting $arch and $os mixed up?
by Hackage 07 Feb '10

07 Feb '10

#629: cabal-install getting $arch and $os mixed up? ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ---------------------------------+------------------------------------------ In my .cabal/config I have {{{ install-dirs user prefix: /home/simonmar/.cabal bindir: $prefix/bin/$arch-$os -- libdir: $prefix/lib libsubdir: $pkgid/$compiler/$arch-$os -- libexecdir: $prefix/libexec -- datadir: $prefix/share -- datasubdir: $pkgid -- docdir: $datadir/doc/$pkgid -- htmldir: $docdir/html -- haddockdir: $htmldir }}} I just cabal-installed darcs-beta, and it said: {{{ Installing library in /home/simonmar/.cabal/lib/darcs-beta-2.3.98.3/ghc-6.12.1/linux-i386 Installing executable(s) in /home/simonmar/.cabal/bin/linux-i386 }}} so apparently it has got `$arc`h and `$os` interchanged. I think this worked in the past, because I have a `~/.cabal/bin/i386-linux` directory with some executables in it. {{{ $ cabal --version cabal-install version 0.8.0 using version 1.8.0.2 of the Cabal library }}} PS. someone needs to add Cabal version 1.8 and GHC version 6.12.1 to the relevant Trac fields -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/629> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2