- cabal-devel - Haskell.org

patch applied (cabal): Add parsse utils for simple flat formats.
by Duncan Coutts 06 Aug '08

06 Aug '08

Wed Aug 6 05:26:13 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add parsse utils for simple flat formats. Should help to simplify the InstalledPackageInfo parser and also for similar formats in cabal-install. M ./Distribution/PackageDescription/Parse.hs -1 +1 M ./Distribution/ParseUtils.hs +26 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080806122613-adfee-ae7eeb30…

1 0

patch applied (cabal): Tidy up the ppFields function and uses
by Duncan Coutts 06 Aug '08

06 Aug '08

Wed Aug 6 05:13:15 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Tidy up the ppFields function and uses Put the arguments in a more sensible order: ppFields :: [FieldDescr a] -> a -> Doc and make the implementation clearer. clean up the use of it in the PackageDescription.Parse module M ./Distribution/InstalledPackageInfo.hs -1 +1 M ./Distribution/PackageDescription/Parse.hs -17 +19 M ./Distribution/ParseUtils.hs -4 +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080806121315-adfee-b3a04a6a…

1 0

patch applied (cabal): Windows fixes
by Simon Marlow 06 Aug '08

06 Aug '08

Sun Aug 3 13:12:53 PDT 2008 Ian Lynagh <igloo(a)earth.li> * Windows fixes M ./Distribution/Compat/Exception.hs -8 +17 M ./Distribution/Simple/Utils.hs -3 +6 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080803201253-3fd76-74cf4411…

1 0

patch applied (cabal): setup makefile: put the source-dir suffix rules after the distdir suffix rules
by Simon Marlow 06 Aug '08

06 Aug '08

Wed Aug 6 06:03:09 PDT 2008 Simon Marlow <marlowsd(a)gmail.com> * setup makefile: put the source-dir suffix rules after the distdir suffix rules This matches the behaviour of 'setup build' works, and is robust to people accidentally having old preprocessed sources lying around in the source dir. M ./Distribution/Simple/GHC.hs -1 +8 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080806130309-12142-87dbaa5c…

1 0

Re: Where should cabal install to by default?
by Isaac Dupree 06 Aug '08

06 Aug '08

Jeffrey Yasskin wrote: > FWIW, Python recently went through this exercise and produced > http://python.org/dev/peps/pep-0370/, which does use the $HOME/.local > directory. I don't know how much that should affect Cabal's choice, > but it's a bit of prior art if you're interested. It seems $HOME/.local/bin is shared between all programs, unlike e.g. $HOME/.local/lib/python2.6/ ? Of course this is how /usr/local works already. But I wonder if we should put the actual binaries somewhere else, and just put symlinks in that "bin" directory. What if the pythoners accidentally call some program "happy" and it conflicts with the binary derived from haskell's Hackage? (Of course that would be a problem for other reasons, but it's worse if it requires overwriting unknown binaries with binaries rather than symlinks vs. symlinks.) -Isaac

1 0

patch applied (cabal): Generalise checkPackageFiles to any monad, not just IO
by Duncan Coutts 06 Aug '08

06 Aug '08

Tue Aug 5 17:15:47 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Generalise checkPackageFiles to any monad, not just IO This is to let us use the same checks for virtual or in-memory file systems, like tarball contents. M ./Distribution/PackageDescription/Check.hs -26 +66 M ./Distribution/Simple/SrcDist.hs +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080806001547-adfee-637fe706…

1 0

patch applied (cabal): Move parseFreeText into ParseUtils and use it more widely
by Duncan Coutts 06 Aug '08

06 Aug '08

Tue Aug 5 17:13:52 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Move parseFreeText into ParseUtils and use it more widely M ./Distribution/InstalledPackageInfo.hs -9 +6 M ./Distribution/PackageDescription/Parse.hs -11 +10 M ./Distribution/ParseUtils.hs -1 +4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080806001352-adfee-414a03fd…

1 0

patch applied (cabal): Document and refactor 'parsePackageDescription'.
by Duncan Coutts 06 Aug '08

06 Aug '08

Mon Aug 4 12:03:24 PDT 2008 Thomas Schilling <nominolo(a)googlemail.com> * Document and refactor 'parsePackageDescription'. Hopefully this makes this function more understandable and easier to modify. M ./Distribution/PackageDescription/Parse.hs -39 +86 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080804190324-7c5c6-59960c58…

1 0

[Hackage] #319: Warn if the source file for a module is ambigious.
by Hackage 05 Aug '08

05 Aug '08

#319: Warn if the source file for a module is ambigious. ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------+----------------------------------------------- For example if we are looking for a module `Foo` and there are files `Foo.hs` and `Foo.y` then we should use `Foo.y` as we do now, but we should warn about the presence of `Foo.hs` (and note the fact that we're ignoring it). Similarly if we find `Foo.x` and `Foo.y` then we should warn about the one we're not using. Or arguably that should be a straight error. There's an obvious order relation between `Foo.hs` and `Foo.y` but not between `Foo.x` and `Foo.y`. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/319> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: head aches in parser/Parser.hs
by Duncan Coutts 05 Aug '08

05 Aug '08

On Tue, 2008-08-05 at 22:11 +1000, Roman Leshchinskiy wrote: > On 05/08/2008, at 21:15, Duncan Coutts wrote: > > > It knows that .y can be pre-processed to .hs so if it finds both .hs > > and .y then it knows that .y is the ultimate source file and > > pre-processes that. > > > > Do you think this is the wrong behaviour or are you observing > > different > > behaviour? > > I think I'm observing a different behaviour. I don't think a Parser.hs > left over from a previous build would have affected the build with the > behaviour you describe. I suspect it might be different behaviour between the cabal build and the makefile that the ghc build system generates. I just tried it with a simple test case and with cabal build it works how I expected. For the makefiles I defer to Ian and Simon. > Out of idle curiousity, what happens if Cabal finds both Foo.y and > Foo.x? Is all this documented somewhere? I couldn't find anything in > the Cabal docs but maybe I just looked in the wrong place. That's essentially undefined. It'll depend on the order in which we check the .x and .y suffix rules. That's the kind of ambiguous case I was suggesting we should warn about. Duncan

1 0