August 2008 - cabal-devel

patch applied (cabal): In wrappers, $executablename needs to expand to something with DESTDIR
by Ian Lynagh 30 Aug '08

30 Aug '08

Thu Aug 28 08:55:54 PDT 2008 Ian Lynagh <igloo(a)earth.li> * In wrappers, $executablename needs to expand to something with DESTDIR The installed wrapper needs to call the executable in its final place, not inside the DESTDIR where we are constructing a package. M ./Distribution/Simple/GHC.hs -1 +4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080828155554-3fd76-9b4ff184…

1 0

patch applied (cabal): Allow passing haddock's location and options to "Setup haddock"
by Ian Lynagh 30 Aug '08

30 Aug '08

Thu Aug 28 07:24:24 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Allow passing haddock's location and options to "Setup haddock" M ./Distribution/Simple.hs -3 +18 M ./Distribution/Simple/Program.hs +9 M ./Distribution/Simple/Setup.hs -1 +17 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080828142424-3fd76-f46d3d8f…

1 0

patch applied (cabal): We need to pass the CPP options to haddock 2
by Ian Lynagh 30 Aug '08

30 Aug '08

Thu Aug 28 07:23:03 PDT 2008 Ian Lynagh <igloo(a)earth.li> * We need to pass the CPP options to haddock 2 M ./Distribution/Simple/Haddock.hs +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080828142303-3fd76-6927ac56…

1 0

patch applied (cabal): Add support for manually en/disabled flags
by Ian Lynagh 30 Aug '08

30 Aug '08

Wed Aug 27 10:01:05 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Add support for manually en/disabled flags The immediate use for these is so that, in haddock, we can require ghc-paths normally, but in the GHC build we can manually turn off a flag so that this dependency isn't needed. We can't use a normal flag, or in the normal build Cabal would infer that the flag needs to be turned off if ghc-paths isn't available. M ./Distribution/PackageDescription.hs -2 +4 M ./Distribution/PackageDescription/Configuration.hs -2 +6 M ./Distribution/PackageDescription/Parse.hs -1 +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080827170105-3fd76-1c25affd…

1 0

Hackage complains about data-dir
by Neil Mitchell 27 Aug '08

27 Aug '08

Hi, The new version of Hoogle uses data-dir in the main section of the Cabal file. http://code.haskell.org/hoogle/hoogle.cabal Uploading to hackage gives: 400 Error in upload hoogle-4.0.0.5/hoogle.cabal: Unknown fields: data-dir (line 19) Fields allowed in this section: name, version, cabal-version, build-type, license, license-file, copyright, maintainer, build-depends, stability, homepage, package-url, synopsis, description, category, author, tested-with, data-files, extra-source-files, extra-tmp-files But the documentation says: http://haskell.org/cabal/release/latest/doc/users-guide/authors.html#genera… Who is right? Who is wrong? If I'm wrong, what is the fix? Thanks Neil

3 8

[Hackage] #345: Build Tree Proposal
by Hackage 26 Aug '08

26 Aug '08

#345: Build Tree Proposal ----------------------------+----------------------------------------------- Reporter: cjs | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: Other Unix | ----------------------------+----------------------------------------------- I've noticed a few issues with cabal for which I have a proposed solution. 1. Currently, if you have two different executables that use the same build options and mostly the same source, the .o files that they share are compiled twice and stored in separate locations, costing both CPU time and disk space. It would be preferable never to compile a .o file more than once with the same set of options. 2. It's handy, when using runhaskell and ghci in your source tree, to be able to freely run either on any source file and have them use any compiled binaries that are available. With the current way Cabal builds things, except in simple projects with only one target, there is no single directory that contains all of the compiled files. Instead there is a separate directory for each target that contains only the files necessary to build that particular target. This leaves no optimal choice for the -hidir and -odir options of runhaskell and ghci. 3. It's not uncommon to build several different executables from the same set of source files with the same build options. Currently the specificiation for this is verbose and repetitive, since all options must be repeated for every executable. A possible change that would help to mitigate all three of these problems, while being fully backward compatable, would be to introduce the concept of a "build tree"; a single build directory that would contain all of the object files built from a given source tree. This would be specified in the cabal file in the same way that an executable or a library is specified, and would make use of the same hs-source-dirs, extensions, build-depends and similar options. However, within a build section it would be possible also to specify that specific libraries and/or executables be built from that build tree. These subsections would use main-is, exposed-modules and similar options that are currently used by top-level executable and library declarations. Note that this would require, for GHC builds at least, #179 to be implemented, and it would appear to provide the feature requested in #276. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/345> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): Add release date of 1.4.0.2
by Duncan Coutts 26 Aug '08

26 Aug '08

Tue Aug 26 13:48:10 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add release date of 1.4.0.2 M ./changelog -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080826204810-adfee-ca424015…

1 0

patch applied (cabal): Ban package names that are not valid windows file names
by Duncan Coutts 26 Aug '08

26 Aug '08

Mon Aug 25 17:55:02 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Ban package names that are not valid windows file names At least for the purposes of distribution. So if you're on unix then you can call your package 'LPT1' if you feel you must, but you cannot distribute a package with this name. M ./Distribution/PackageDescription/Check.hs -1 +10 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080826005502-adfee-ea18a747…

1 0

patch applied (cabal): Separate out and export installDirsOptions
by Duncan Coutts 26 Aug '08

26 Aug '08

Mon Aug 25 17:32:40 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Separate out and export installDirsOptions The InstallDirs is a separate type so it's handy to have the command line and config file options for it available separately. It'd be useful in cabal-install for one thing. M ./Distribution/Simple/Setup.hs -59 +66 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080826003240-adfee-279adc5e…

1 0

[Hackage] #344: document all the language extensions
by Hackage 26 Aug '08

26 Aug '08

#344: document all the language extensions ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.2 Platform: | ------------------------------+--------------------------------------------- The module `Language.Haskell.Extension` serves as a kind of central registry of all Haskell language extensions. It is shared between the various Haskell implementations. Currently it's just a big list which is quite unhelpful. All new extensions are now required to come with documentation but we need someone to go through the existing list and copy documentation and convert it into haddock format. The best existing source of documentation for language extensions is the ghc user guide. This is a nice standalone task that anyone with a bit of spare time could do. No knowledge of Cabal is required. It can even be done incrementally. Send you patches to the cabal-devel mailing list or attach them to this ticket. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/344> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0