- cabal-devel - Haskell.org

Ticket #164
by Brent Yorgey 26 Jan '08

26 Jan '08

Hi cabal folks! In an effort to help out with Cabal stuff, I'm going to start by taking a crack at ticket #164 on the trac (bad error message with undefined flags). Just thought I would claim it as "mine" so no one else steals my lollipop. =) cheers, -Brent

2 1

patch applied (cabal): Replace remaining OPTIONS pragmas with LANGUAGE + OPTIONS_GHC/JHC/NHC98
by Duncan Coutts 26 Jan '08

26 Jan '08

Wed Jan 23 13:19:23 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Replace remaining OPTIONS pragmas with LANGUAGE + OPTIONS_GHC/JHC/NHC98 ghc-6.4 and above recognise the OPTIONS_GHC pragma. ghc-6.6 and above recognise the LANGUAGE pragma. Added OPTIONS_JHC and OPTIONS_NHC pragmas with equivalant flags. M ./Distribution/Compat/ReadP.hs -1 +4 M ./Distribution/Compat/TempFile.hs -1 +4 M ./Distribution/Compiler.hs -1 +4 M ./Distribution/Configuration.hs -1 +4 M ./Distribution/PackageDescription.hs -1 +4 M ./Distribution/ParseUtils.hs -1 +4 M ./Distribution/Simple/Build.hs -2 +3 M ./Distribution/Simple/InstallDirs.hs -1 +4 M ./Distribution/Simple/Utils.hs -1 +4 M ./Distribution/Version.hs -1 +4

2 2

patch applied (cabal): Add a Distribution.Setup module that re-exports Distribution.Simple.Setup
by Duncan Coutts 25 Jan '08

25 Jan '08

Thu Sep 20 05:11:25 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Add a Distribution.Setup module that re-exports Distribution.Simple.Setup Many Setup.hs files import Distribution.Setup so this unbreaks them. It's marked DEPRECATED so will generate a warning for scripts that use it. This patch is only going to the cabal-1.2 branch, not HEAD. M ./Cabal.cabal +1 A ./Distribution/Setup.hs

1 1

patch applied (cabal): Document the fact that --user now changes the default --prefix
by Duncan Coutts 25 Jan '08

25 Jan '08

Wed Jan 23 18:53:52 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Document the fact that --user now changes the default --prefix to $HOME/.cabal on unix and on WinXP: (not sure about vista) C:\Documents And Settings\user\Application Data\cabal M ./doc/Cabal.xml -13 +24

1 0

patch applied (cabal): flush stdout before running subprograms
by Ross Paterson 25 Jan '08

25 Jan '08

Fri Jan 25 02:20:53 PST 2008 Ross Paterson <ross(a)soi.city.ac.uk> * flush stdout before running subprograms This is needed to separate Cabal and subprogram output if stdout is buffered (e.g. a file), especially if stdout and stderr are the same. M ./Distribution/Simple/Utils.hs +1

1 0

Re: [Hackage] #11: declare what is stable cabal interface.
by Hackage 25 Jan '08

25 Jan '08

#11: declare what is stable cabal interface. ----------------------------+----------------------------------------------- Reporter: ijones | Owner: Type: task | Status: closed Priority: normal | Milestone: Cabal-1.2 Component: Cabal library | Version: Severity: major | Resolution: fixed Keywords: | Difficulty: hard Ghcversion: 6.2.1 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: The info from the StableInterfaces wiki page is now in the user guide. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/11#comment:9> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): Update user guide on reporting bugs and stability of cabal interfaces
by Duncan Coutts 25 Jan '08

25 Jan '08

Thu Jan 24 12:12:50 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Update user guide on reporting bugs and stability of cabal interfaces Fixes ticket #11. Though the section could do with a bit more detail. It corresponds to what's on the wiki: http://hackage.haskell.org/trac/hackage/wiki/StableInterfaces M ./doc/Cabal.xml -40 +127

1 0

Re: [Hackage] #131: cabal-install should rebuild dependants when a package is upgraded
by Hackage 24 Jan '08

24 Jan '08

#131: cabal-install should rebuild dependants when a package is upgraded ---------------------------------+------------------------------------------ Reporter: bringert | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-2.0 Component: cabal-install tool | Version: HEAD Severity: normal | Resolution: Keywords: | Difficulty: hard (< 1 day) Ghcversion: 6.6 | Platform: Linux ---------------------------------+------------------------------------------ Comment (by guest): A real-life "war story" that seems to illustrate the problem, or at least be closely related: I used 'cabal upgrade' to upgrade a bunch of packages, in particular bytestring and various regex-*, since I wanted to install something that depended on them. Later, however, I tried to install Yi, which as it turns out was incompatible with the latest version of bytestring. I downgraded bytestring, but then had to rebuild vty (so it would be built with the older bytestring) and also unregister many of the newer versions of the regex-* packages, since Yi depended on them; with the newer versions installed, they were chosen to fulfill Yi's dependencies, but those newer versions depended on the newest version of bytestring, which was no longer installed. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/131#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #57: maybe: each new package uploaded to hackageDB should create a component in trac?
by Hackage 24 Jan '08

24 Jan '08

#57: maybe: each new package uploaded to hackageDB should create a component in trac? --------------------------------+------------------------------------------- Reporter: ijones | Owner: ijones Type: enhancement | Status: new Priority: low | Milestone: _|_ Component: HackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: --------------------------------+------------------------------------------- Changes (by duncan): * priority: normal => low * platform: Linux => -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/57#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #195: Specify include and library paths that are used for building the package only
by Hackage 24 Jan '08

24 Jan '08

#195: Specify include and library paths that are used for building the package only ---------------------+------------------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.3.0 Severity: normal | Keywords: jgoerzen(a)complete.org Difficulty: normal | Ghcversion: 6.8.1 Platform: Linux | ---------------------+------------------------------------------------------ From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293523 {{{ Specify include and library paths that are used for building the package only, and do not end up in the GHC packages file. }}} I think this needs more explanation. There is certainly a use case for includes that are used to pre-process Haskell code since they are never needed when building dependent packages. On the other hand, library paths to find libraries to link to are always required by dependent packages as far as I know since to link an executable using a package that uses a library we have to specify the library and search path. There is no way with GHC to limit where a C header file might be needed. If a header file is needed to compile a package, then the header file might also be needed to compile code that uses the package due to cross- package inlining. If GHC does gain the feature to limit the scope of where C headers are required then we will want to support that in Cabal, possibly via package-local headers. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/195> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1