December 2007 - cabal-devel

patch applied (cabal): Make all command line flags and flag collection types monoids
by Duncan Coutts 17 Dec '07

17 Dec '07

Sat Dec 15 11:36:50 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Make all command line flags and flag collection types monoids And specify command flags in a way that allows converting from or two strings. So not only can we parse command lines into the various flag types, we can convert back. This is crucial in cabal-install so that we can call Setup.hs scripts with all the various args, and override certain flags in a typed way rather than just representing them all as strings. M ./Distribution/Make.hs -15 +16 M ./Distribution/Simple.hs -45 +43 M ./Distribution/Simple/Build.hs -6 +6 M ./Distribution/Simple/Command.hs -36 +122 M ./Distribution/Simple/Configure.hs -27 +38 M ./Distribution/Simple/GHC.hs -6 +6 M ./Distribution/Simple/Haddock.hs -14 +18 M ./Distribution/Simple/Install.hs -3 +5 M ./Distribution/Simple/Register.hs -14 +15 M ./Distribution/Simple/Setup.hs -442 +875 M ./Distribution/Simple/SrcDist.hs -2 +4

1 0

patch applied (cabal): Export Command constructor so cabal-install can make derived commands
by Duncan Coutts 17 Dec '07

17 Dec '07

Sat Dec 8 11:24:01 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Export Command constructor so cabal-install can make derived commands Also move commandHelp out of the structure into a helper function. Change the type of commandOptions so it doesn't include the CommonFlag. Instead, add those in whenever necessary. This makes deriving commands easier. Also fix docs. M ./Distribution/Simple/Command.hs -13 +17

1 0

patch applied (cabal): Replace lots of configBlahDir fields with just one InstallDirs
by Duncan Coutts 17 Dec '07

17 Dec '07

Sat Dec 8 10:26:20 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Replace lots of configBlahDir fields with just one InstallDirs So instead of 10 fields like this: configPrefix :: Maybe FilePath, ... we have just one compound one: configInstallDirs :: InstallDirs (Maybe FilePath) Now that LocalBuildInfo and cabal-install's config use InstallDirs it makes converting a lot easier since we can use fmap and combineInstallDirs. This should also be easier to maintain as it has significantly reduced the number of places in the code you have to change when you add/change a dir. M ./Distribution/Simple/Configure.hs -15 +3 M ./Distribution/Simple/InstallDirs.hs +1 M ./Distribution/Simple/Setup.hs -45 +22

1 0

patch applied (cabal): Merge InstallDirTemplates into InstallDirs
by Duncan Coutts 17 Dec '07

17 Dec '07

Sat Dec 8 10:23:34 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Merge InstallDirTemplates into InstallDirs This simplifies things and makes it a bit more versatile since we can use things like InstallDirs (Maybe PathTemplate). M ./Distribution/Simple/Configure.hs -12 +11 M ./Distribution/Simple/Haddock.hs -2 +2 M ./Distribution/Simple/InstallDirs.hs -148 +166 M ./Distribution/Simple/Register.hs -11 +11

1 0

[Hackage] #192: unlink files before copying over them
by Hackage 17 Dec '07

17 Dec '07

#192: unlink files before copying over them ---------------------+------------------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.1 Platform: Linux | ---------------------+------------------------------------------------------ From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336417 {{{ It would be nice if cabal would unlink destination files before installing over them, rather than just calling "copyFile". It appears that when "copyFile" finds that a destination file already exists, rather than removing it, it tries to open and truncate it, which leads cabal to fail with the following error message when a new version of a running program is installed: *** Exception: bar: copyFile: resource busy (Text file busy) The commonly-used 'install' command does not suffer from this bug. }}} So I think we need to make a portable installFile function that does the right thing on Unix and Windows. At the same time we should think about permissions and bug #93. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/192> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

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

17 Dec '07

#89: Sharing of object files between executable builds? ------------------------------------+--------------------------------------- Reporter: bjorn(a)bringert.net | Owner: ijones Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal | Version: Severity: minor | Resolution: Keywords: jgoerzen(a)complete.org | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ------------------------------------+--------------------------------------- Comment (by guest): I can't remember if this is already the case, but I think things are much simpler if Cabal only operates on files under dist/, e.g. dist/src/library and dist/src/executable3 for the library and the 3rd executable. That way we don't have to worry about GHC making files like Foo_stub.c in the user's directory, that we'd then have to clean up later, nor do we have to worry about it finding the wrong files in the above case. We just have to remember which modules are in the library and not copy them into disrc/src/executable*. Ian Lynagh -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #100: Remove Setup.hs, use Setup.lhs only
by Hackage 17 Dec '07

17 Dec '07

#100: Remove Setup.hs, use Setup.lhs only -----------------------------+---------------------------------------------- Reporter: igloo(a)earth.li | Owner: ijones Type: enhancement | Status: closed Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: wontfix Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -----------------------------+---------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => wontfix Comment: Replying to [comment:2 guest]: > In the future we'll be using the cabal command rather than running Setup directly, right? So maybe this ticket should just be closed. Yes. Remember it's also possible to use {{{runghc Setup}}} without specifying any .hs or .lhs extension. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/100#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #1: copy Debian bugs here
by Hackage 17 Dec '07

17 Dec '07

#1: copy Debian bugs here ---------------------+------------------------------------------------------ Reporter: ijones | Owner: somebody Type: task | Status: closed Priority: high | Milestone: Component: misc | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: easy Ghcversion: 6.2.2 | Platform: ---------------------+------------------------------------------------------ Changes (by duncan): * status: new => closed * platform: => * ghcversion: => 6.2.2 * resolution: => fixed Comment: Opened #192 #193 #194 #195 #196. All the other bugs or features in the debian bug reports and fixed or implemented. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/1#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

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

17 Dec '07

#89: Sharing of object files between executable builds? ------------------------------------+--------------------------------------- Reporter: bjorn(a)bringert.net | Owner: ijones Type: enhancement | Status: new Priority: low | Milestone: Component: Cabal | Version: Severity: minor | Resolution: Keywords: jgoerzen(a)complete.org | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ------------------------------------+--------------------------------------- Changes (by duncan): * keywords: => jgoerzen(a)complete.org Comment: Also requested in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293523 by John Goerzen (adding to cc list). The technical problem here is that we have to register the library in place and then do the build against that library. We also have to arrange so that when building the executables against the library, we do not end up pulling in the libraries source files in preference to the compiled modules from the built library package. That's a bit tricky if the library and executable source files share the same source directories as will often be the case. I'm not sure if it is possible with ghc --make to prefer the modules in a package to the locally found source files. If not then it would depend on Cabal doing the build without --make using ghc in single-shot mode. See #15. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #100: Remove Setup.hs, use Setup.lhs only
by Hackage 17 Dec '07

17 Dec '07

#100: Remove Setup.hs, use Setup.lhs only -----------------------------+---------------------------------------------- Reporter: igloo(a)earth.li | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -----------------------------+---------------------------------------------- Comment (by guest): In the future we'll be using the cabal command rather than running Setup directly, right? So maybe this ticket should just be closed. Ian -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/100#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0