- cabal-devel - Haskell.org

patch applied (cabal): Add PackageSet.topologicalOrder and reverseTopologicalOrder
by Ian Lynagh 22 Jul '08

22 Jul '08

Sun Jul 20 15:37:31 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add PackageSet.topologicalOrder and reverseTopologicalOrder with type :: PackageFixedDeps pkg => PackageSet pkg -> [pkg] M ./Distribution/Simple/PackageSet.hs +15 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080720223731-adfee-e51cad76…

1 0

patch applied (cabal): Change some PackageSet functions to return the package rather than the id
by Ian Lynagh 22 Jul '08

22 Jul '08

Sun Jul 20 15:17:02 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Change some PackageSet functions to return the package rather than the id dependencyGraph and reverseDependencyClosure now return the full package rather than just the PackageIdentifier M ./Distribution/Simple/PackageSet.hs -6 +7 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080720221702-adfee-3b9dadd7…

1 0

patch applied (cabal): Convert from PackageIndex to PackageSet
by Ian Lynagh 22 Jul '08

22 Jul '08

Sun Jul 20 12:49:24 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Convert from PackageIndex to PackageSet Turns out the feature to do case-insensitive lookups was only needed in cabal-install (and only in one little part) and elsewhere it causes problems. So use PackageSet instead. M ./Distribution/PackageDescription/Configuration.hs -6 +6 M ./Distribution/Simple/Configure.hs -14 +14 M ./Distribution/Simple/GHC.hs -4 +4 M ./Distribution/Simple/Haddock.hs -2 +2 M ./Distribution/Simple/JHC.hs -4 +4 M ./Distribution/Simple/LocalBuildInfo.hs -2 +2 M ./Distribution/Simple/PackageIndex.hs -152 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080720194924-adfee-c1b24018…

1 0

patch applied (cabal): If we have GHC >= 6.9 then use the new -optdep replacement flags
by Ian Lynagh 22 Jul '08

22 Jul '08

Tue Jul 22 09:33:46 PDT 2008 Ian Lynagh <igloo(a)earth.li> * If we have GHC >= 6.9 then use the new -optdep replacement flags M ./Distribution/Simple/GHC.hs -1 +5 M ./Distribution/Simple/GHC/Makefile.hs -1 +1 M ./Distribution/Simple/GHC/Makefile.in -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080722163346-3fd76-1f4321e8…

1 0

patch applied (cabal): And exitcode of 2 from ghc-pkg when doing describe '*' means no packages
by Ian Lynagh 22 Jul '08

22 Jul '08

Tue Jul 22 05:57:59 PDT 2008 Ian Lynagh <igloo(a)earth.li> * And exitcode of 2 from ghc-pkg when doing describe '*' means no packages This is a bit of a kludge around GHC's #2201, until Cabal is updated to use ghc-pkg dump. M ./Distribution/Simple/GHC.hs -6 +12 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080722125759-3fd76-ebb51572…

1 0

patch applied (cabal): Fix warnings and add a comment explaining why we pass -x to strip on OS X
by Ian Lynagh 22 Jul '08

22 Jul '08

Sun Jul 20 15:08:51 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Fix warnings and add a comment explaining why we pass -x to strip on OS X M ./Distribution/Simple/GHC.hs -3 +6 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080720220851-3fd76-d75b94b3…

1 0

patch applied (cabal): Pass -x to strip on OSX
by Ian Lynagh 22 Jul '08

22 Jul '08

Sun Jul 20 13:46:09 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Pass -x to strip on OSX M ./Distribution/Simple/GHC.hs -1 +5 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080720204609-adfee-80fd5794…

1 0

patch applied (cabal): Generate expanded makefile rules directly, rather than using $(eval ...)
by Ian Lynagh 20 Jul '08

20 Jul '08

Sun Jul 20 12:48:01 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Generate expanded makefile rules directly, rather than using $(eval ...) We used to do this with $(eval ...) and $(call ...) in the Makefile, but make 3.79.1 (which is what comes with msys) doesn't understand $(eval ...), so now we just stick the expanded loop directly into the Makefile we generate. M ./Distribution/Simple/GHC.hs -3 +52 M ./Distribution/Simple/GHC/Makefile.hs -1 +1 M ./Distribution/Simple/GHC/Makefile.in -50 +6 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080720194801-3fd76-3ecbe1b5…

1 0

Re: consistency in "ghc-pkg field '*' haddock-html"?
by Duncan Coutts 20 Jul '08

20 Jul '08

On Sat, 2008-07-19 at 21:58 +0100, Claus Reinke wrote: > >> - some entries '/', some use '\\', some use a combination of > >> '/' and *unescaped* '\' (the latter two come from ghc's > >> cabal configure run either with or without --prefix) > > > > That's fine. They use \\ when using Haskell String format. When not then > > windows accepts both \ and / as path separators, it's not an escape > > char. > > Since windows is so forgiving, why not be consistent and always > use '/'? We do. But if someone passes Cabal a path containing '\' then we don't interpret or check it, we just use it. > That also reduces the number of escapes as well as the > danger of missing escapes when going via several levels of > shells/interpretation. Only the double quotes to protect spaces > remain necessary. The convention everywhere in Cabal (and in the ghc-pkg registration files) is to allow Haskell String syntax. It's only essential when one wants to use characters that would otherwise be interpreted as separators. > > It's not strictly necessary for ghc-pkg to know where index files are > > that cover various packages but it would be nice to do something better > > there. People ask for Cabal to maintain an index over all packages > > though it's not clear where it should put this. > > For context: I've just extended the haskellmode plugins for Vim > to handle docs for libraries outside code+extra (not yet online), > and while it was no big deal working around all those inconsistencies, > it certainly seemed unnecessary and ugly. > > Right now, only core+extralibs have a unified index, and that can > be found by all kinds of ugly guesses (though ghc-paths will help > there in the future). Once Cabal generates and maintains a master > index, perhaps there could simply be a standard file pointing to it, > in the haddock-html dirs? It would not be per-package of course so I don't think it makes sense to put it in package registration files. Duncan

1 1

Re: consistency in "ghc-pkg field '*' haddock-html"?
by Duncan Coutts 19 Jul '08

19 Jul '08

On Sat, 2008-07-19 at 11:02 +0100, Claus Reinke wrote: > When I issue the command from the subject line in a relatively > bare built-from-darcs GHC HEAD on windows, this is what I get: > > $ ghc-pkg field '*' haddock-html > haddock-html: > haddock-html: file:///c:/ghc/ghc-6.9.20080514/doc/libraries/ghc-prim > haddock-html: file:///c:/ghc/ghc-6.9.20080514/doc/libraries/integer > haddock-html: file:///c:/ghc/ghc-6.9.20080514/doc/libraries/base > haddock-html: file:///c:/ghc/ghc-6.9.20080514/doc/libraries/array > .. > haddock-html: c:/ghc/ghc-6.9.20080514/html/libraries/ghc > haddock-html: c:/ghc/libraries\doc\ghc-paths-0.1.0.1\html > haddock-html: c:/ghc/libraries\doc\haskell-src-exts-0.3.4\html > haddock-html: "C:\\Program Files\\Haskell\\doc\\uniplate-1.2.0.1\\html" > > The first empty line is from rts (as you can confim by using > ghc-pkg field '*' name,haddock-html instead), which is correct, > as that package has no Haddocks. But note the rest: > > - some entries '/', some use '\\', some use a combination of > '/' and *unescaped* '\' (the latter two come from ghc's > cabal configure run either with or without --prefix) That's fine. They use \\ when using Haskell String format. When not then windows accepts both \ and / as path separators, it's not an escape char. > - some entries are URLs, some entries are path names Yeah, that's not good. > - the entry for the ghc package is a lie (the html/ directory > doesn't exist, and the doc/html/libraries/ directory has > no ghc package docs) Blame the ghc build system :-) > - while the paths for the core and extra libraries are strictly > speaking correct, there is no indication that all of them > have been integrated into a unified index (one level up), > in contrast to the addon packages, which have their own > indices > > It would be helpful if the consistency and usefulness of this > data could be improved, eg, cabal always using '/' and be > consistent in its escape strategy, ghc and cabal using either > all URLs or all path names, not adding paths for non-existing > docs, and having some indication of whether the package docs > have been integrated into some global documentation index. Cabal uses whatever path the user tells us to use. Whenever Cabal makes up its own paths it uses the standard path separator for the platform. When the path contains spaces it has to use the String format because space is a field separator. So the problems as I see it are why the core packages are using urls. It's not strictly necessary for ghc-pkg to know where index files are that cover various packages but it would be nice to do something better there. People ask for Cabal to maintain an index over all packages though it's not clear where it should put this. Duncan

1 0