- cabal-devel - Haskell.org

patch applied (cabal-install): Rearrange config settings and global command line settings
by Duncan Coutts 22 Aug '08

22 Aug '08

Thu Aug 21 14:05:55 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Rearrange config settings and global command line settings The intention here is to have the config file content and parser be derivied from the command line types and flags. Now instead of having a saved config type that contains additional information to that kept in command line parameters we now put all the information in the command line settings type and make the saved config just the aggregation of the settings for various key commands like configure, install, upload. There's also an extended GlobalFlags type with the things like repos, cache dir etc. When we generate the initial config file we put in commented out versions of all (non-deprecated) valid fields, along with their default values. The aim is to make the config file self-documenting. M ./Distribution/Client/Config.hs -223 +262 R ./Distribution/Client/ParseUtils.hs M ./Distribution/Client/Setup.hs -27 +182 M ./Main.hs -108 +106 M ./cabal-install.cabal -1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080821210555-adfee-…

1 0

patch applied (cabal): Don't pass cc-options to Haskell compilations
by Simon Marlow 21 Aug '08

21 Aug '08

Thu Aug 21 06:34:21 PDT 2008 Simon Marlow <marlowsd(a)gmail.com> * Don't pass cc-options to Haskell compilations This has no effect with GHC 6.9, and with earlier GHC's it was a misuse of cc-options. M ./Distribution/Simple/GHC.hs -1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080821133421-12142-37564695…

1 0

patch applied (cabal): Don't propagate cc-options to the InstalledPackageInfo
by Simon Marlow 21 Aug '08

21 Aug '08

Thu Aug 21 06:25:51 PDT 2008 Simon Marlow <marlowsd(a)gmail.com> * Don't propagate cc-options to the InstalledPackageInfo cc-options is for options to be passed to C compilations in the current package. If we propagate those options to the InstalledPackageInfo, they get passed to C compilations in any package that depends on this one, which could be disastrous. I've seen cc-options like these: cc-options: -optc-std=c99 cc-options: -D_FILE_OFFSET_BITS=64 Cc-options: -Wall these are all clearly intended to be local, but are in fact currently propagated to all dependent packages. M ./Distribution/Simple/Register.hs -2 +5 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080821132551-12142-e4ddc118…

1 0

[Hackage] #334: GHC_PACKAGE_PATH with trailing colon disrespected
by Hackage 21 Aug '08

21 Aug '08

#334: GHC_PACKAGE_PATH with trailing colon disrespected ----------------------------+----------------------------------------------- Reporter: cjs | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: Other Unix | ----------------------------+----------------------------------------------- Cabal appears not to interpret a GHC_PACKAGE_PATH with a trailing colon (under Unix; this would be a trailing semicolon under Windows) to use the system packages after the ones specified in the path, here, vidēre licet: {{{ $ export GHC_PACKAGE_PATH=/my/package.conf $ runghc Setup.lhs configure Configuring binary-0.4.1... Setup.lhs: At least the following dependencies are missing: base >=2.0&&<2.2, base <3.0 }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/334> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #326: Cabal should support Cabal-version-dependent Setup.hs
by Hackage 20 Aug '08

20 Aug '08

#326: Cabal should support Cabal-version-dependent Setup.hs ----------------------------+----------------------------------------------- Reporter: claus | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- The manual says about non-standard `Setup.hs`: "good luck". But there are packages that need non-standard `Setup.hs`, often just very small ones. And all of them risk breakage when Cabal changes. The first issue is to specify the dependency on a particular Cabal version (#284). The next issue is that package authors often know how to write their `Setup.hs` for different versions of Cabal, but have to pick one or the other. It would be better to have `Setup.hs` code adapt to as many Cabal versions as possible. Since version mismatch leads to compile errors, that seems to imply either - separate sources (`Setup-v1.4.hs`, `Setup-v1.5.hs`, etc.) - one source, with CPP (#if Cabal==1.4 ..) If I read [http://www.haskell.org/pipermail/cabal- devel/2008-August/003576.html Add auto-generated CPP macros for package version testing] correctly, that almost provides package version info via CPP. It would only need to provide precise versions instead of lower bounds, and for the Cabal package. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/326> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 12

Re: [Hackage] #283: install command doesn't install dist/doc/users-guide/
by Hackage 20 Aug '08

20 Aug '08

#283: install command doesn't install dist/doc/users-guide/ ----------------------------------------------+----------------------------- Reporter: Misha Aizatulin <avatar(a)hot.ee> | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: very hard (<1 week) Ghcversion: 6.8.2 | Platform: ----------------------------------------------+----------------------------- Comment (by duncan): See also #330. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/283#comment:7> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #329: Cabal regenerates Paths_package unnecessarily
by Hackage 19 Aug '08

19 Aug '08

#329: Cabal regenerates Paths_package unnecessarily ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- Every time I run {{{cabal install}}}, cabal rebuilds and relinks part of my application, because it generates a fresh Paths_package, even though it is the same. When overwriting Paths_package Cabal should first check to see if the code changes, and if not, not write anything. Example of the bug: {{{ C:\Neil\hoogle>cabal --version cabal-install version 0.5.2 using version 1.4.0.1 of the Cabal library C:\Neil\hoogle>cabal install Resolving dependencies... Configuring hoogle-4.0.0.4... Preprocessing executables for hoogle-4.0.0.4... Building hoogle-4.0.0.4... [ 4 of 77] Compiling Paths_hoogle ( dist\build\autogen/Paths_hoogle.hs, dist \build\hoogle\hoogle-tmp/Paths_hoogle.o ) Linking dist\build\hoogle\hoogle.exe ... Installing: C:\Documents and Settings\Administrator\Application Data\cabal\bin C:\Neil\hoogle>cabal install Resolving dependencies... Configuring hoogle-4.0.0.4... Preprocessing executables for hoogle-4.0.0.4... Building hoogle-4.0.0.4... [ 4 of 77] Compiling Paths_hoogle ( dist\build\autogen/Paths_hoogle.hs, dist \build\hoogle\hoogle-tmp/Paths_hoogle.o ) Linking dist\build\hoogle\hoogle.exe ... Installing: C:\Documents and Settings\Administrator\Application Data\cabal\bin }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/329> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

cabal-install calls setup with unrecognised distpref flag
by José Pedro Magalhães 19 Aug '08

19 Aug '08

Hello all, Recently, while developing a package here in the group, we changed the build-type from "Simple" to "Custom" to allow for "cabal test". The Setup.hs simply calls defaultMainWithHooks with simpleUserHooks where runTests has been redefined. The problem is that this change gives me the following error when invoking "cabal build" (after invoking "cabal configure"): setup.exe: Unrecognised flags: --distpref=dist runhaskell Setup.hs build works fine, though. This happens on a win64 machine, cabal-install version 0.5.1 using version 1.4.0.1 of the library. On a mac there seem to be no problems, though. Am I doing something wrong? Thanks, Pedro

2 3

patch applied (cabal): Fix spelling of compatibility
by Duncan Coutts 18 Aug '08

18 Aug '08

Mon Aug 18 12:49:51 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Fix spelling of compatibility At request of gwern who found that it was driving him nuts. M ./Distribution/License.hs -1 +1 M ./Distribution/Simple.hs -2 +2 M ./Distribution/Simple/InstallDirs.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080818194951-adfee-a662bcff…

1 0

patch applied (cabal): Minor info and help message improvements
by Duncan Coutts 18 Aug '08

18 Aug '08

Wed Aug 13 05:49:57 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Minor info and help message improvements M ./Distribution/Simple/Install.hs -2 +2 M ./Distribution/Simple/Setup.hs -1 +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080813124957-adfee-ffd004ea…

1 0