July 2009 - cabal-devel

patch applied (cabal-install): Make the documentation toggle determine if we make the haddock index
by Duncan Coutts 06 Jul '09

06 Jul '09

Mon Jul 6 18:30:30 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Make the documentation toggle determine if we make the haddock index Previously the --haddock-index=template flag controled both the template used and whether it's used at all. When no path was set then it was not used. The problem with that is that since we are not enabling this feature by default then the default is blank. That is the default config file would look like: -- haddock-index: which doesn't help anyone discover what it means or what a sensible setting would be. By having a separate toggle to enable/disable we can have a default for the index file which makes it easy to discover in the config file: -- documentation: False -- doc-index-file: $datadir/doc/index.html All the user has to do is uncomment the first line and use True. M ./Distribution/Client/Install.hs -3 +4 M ./Distribution/Client/Setup.hs -3 +6 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090707013030-adfee-…

1 0

patch applied (cabal-install): Be less noisy about warning about packages with missing docs
by Duncan Coutts 06 Jul '09

06 Jul '09

Mon Jul 6 17:51:49 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Be less noisy about warning about packages with missing docs M ./Distribution/Client/Haddock.hs -3 +4 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090707005149-adfee-…

1 0

patch applied (cabal-install): Use defaultInstallFlags as the defaults
by Duncan Coutts 06 Jul '09

06 Jul '09

Mon Jul 6 17:48:36 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Use defaultInstallFlags as the defaults M ./Distribution/Client/Install.hs -5 +4 M ./Main.hs -2 +4 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090707004836-adfee-…

1 0

patch applied (cabal-install): Move regenerateHaddockIndex more out-of-line in the Install module
by Duncan Coutts 06 Jul '09

06 Jul '09

Mon Jul 6 17:37:22 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Move regenerateHaddockIndex more out-of-line in the Install module Also update the code somewhat following the changes in the Cabal API for path templates and substitutions. M ./Distribution/Client/Install.hs -39 +66 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090707003722-adfee-…

1 0

patch applied (cabal-install): Use $pkgroot/package/$pkgid.tar.gz as tarball URL
by Duncan Coutts 06 Jul '09

06 Jul '09

Sat Jul 4 10:06:02 PDT 2009 Duncan Coutts <duncan(a)haskell.org> * Use $pkgroot/package/$pkgid.tar.gz as tarball URL M ./Distribution/Client/Fetch.hs -3 +2 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090704170602-adfee-…

1 0

patch applied (cabal-install): #516, maintains a per-user index of haddock docs
by Duncan Coutts 06 Jul '09

06 Jul '09

Sun Jun 7 10:05:12 PDT 2009 Andrea Vezzosi <sanzhiyan(a)gmail.com> * #516, maintains a per-user index of haddock docs Ignore-this: 1114f6b944043781c4bf99620573b1cc If the haddock-index flag is set it keeps an index of the haddock documentation of the packages in the global and user databases A ./Distribution/Client/Haddock.hs M ./Distribution/Client/Install.hs -1 +36 M ./Distribution/Client/Setup.hs +9 M ./cabal-install.cabal +1 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090607170512-cd449-…

1 0

[Hackage] #567: Allow negation of language extension names by adding/removing "No" in front
by Hackage 06 Jul '09

06 Jul '09

#567: Allow negation of language extension names by adding/removing "No" in front ----------------------------+----------------------------------------------- Reporter: SamB | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- GHC supports this, and it could be useful when features are added or removed from the baseline Haskell -- say, record syntax? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/567> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

darcs path: make build reports more accurate for the haddock step
by Andrea Vezzosi 06 Jul '09

06 Jul '09

currently we get DocsOk even when no documentation is created because the package doesn't contain any buildable library, with the following two patches "cabal install" will check and avoid running "setup haddock" if no documentation is going to be created returning DocsNotTried. A possible downside is that we don't get the warning that suggests --executables anymore from "cabal install" (it's still printed when running "cabal haddock"), if that has to be restored we can make hasDocsToBuild print the warning, or make it return the String instead of Bool. We could also make the report even more accurate by making hadDocsToBuild return a list of the components of the package for which it'll produce documentation. The whole thing is a bit nasty without a specified semantic for the Setup haddock command to be respected by Custom build systems. Mon Jul 6 11:23:55 CEST 2009 Andrea Vezzosi <sanzhiyan(a)gmail.com> * expose hasDocsToBuild from D.S.Haddock Mon Jul 6 16:41:00 CEST 2009 Andrea Vezzosi <sanzhiyan(a)gmail.com> * make build reports more accurate for the haddock step

1 0

working on a fix for ticket #212
by Laszlo Nagy 06 Jul '09

06 Jul '09

Hi All, Trying to create unit test suite.. work in progress. Comments are more than welcome! http://sites.google.com/site/rizsotto/patches/cabal-ticket-212-v1.darcs-send As an easy start, I wrote unit tests with QuickCheck on the following files: Distribution/License.hs Distribution/Package.hs Distribution/Compiler.hs Distribution/System.hs Distribution/ModuleName.hs Distribution/PackageDescription.hs I wrote simple properties like this, for all data type > prop_parse x = x == parse $ display x I did merged the existing QuickCheck test cases into one file. I found it easier to reuse the generator functions for different types. My findings: - The System.Platform did not passed parse tests. The reason: both System.OS and System.Arch allowed the dash character in the name. But System.Platform text representation was concatenate the two strings separated by a dash. So I just simple removed the dash from them. Solved! ;) - VersionRange does not passes parse tests, iff more than two ranges is present. As far as I could see, the parse method is wired to handle only two ranges. Not corrected, because found no good solution. Need help on this! - Package.Dependency also not passes parse tests. (It is depend on VersionRange success.) - Compat.ReadR gather property is obsolete and does not compile. Can't figure it out how could I rewrite it. Need help! - PackageDescription does not passes simple parse test. I guess the problem is with the test itself! ;) I used showPackageDescription method to generate string representation of this type and parse it back. I could not judge it is an expected behaviour or a bug. Need some explanation. My problem is mainly how to run these tests? As unit tests they are pure, does not manipulate any files on disks, does not open socket or anything. (Michael Feathers use the unit test word as strict as this.) So, I expected to run them by anyone, who could compile the sources. #1 'cabal test' could be the best way to exercise them. But the user hook is so complicated for a simple 'compile and run'. Found others ignoring the arguments and call System.Cmd, execute _the compiler_. The compiler name is wired and dependencies also not visible enough, not to mention the extension handling. Basically compile by hand is against cabal! :) (Pro: the best way to invoke; Con: very hard to do) #2 Create testing flag in the cabal file, which enable an executable to be build. (Xmonad guys doing this way.) It compiles easy, developer need not worry about different compilers. Running the test can be done by hand (or darcs) or the test user hook can execute it. If the main product is a library, then it does not link against that, since the library is not installed. Instead developers specify the source dir and it recompiles the tested sources. (Pro: easy to do; Cons: does not test against library) #3 Create another cabal file. Roughly speaking it is same as #2. In my opinion it is suite best for functional tests. (Pro: easy to do; Cons: testing target must be installed first) #4 Use the QuickCheck script. Based naming convention this script runs through the sources, 'grep' the properties, and exec an interpreter to run them. (Pro: easy; Cons: interpreter name is wired in the script) #5 As a proposed long term solution: I might add a new parameter to the 'executable' region describe the target is a unit test. Compile (and run) it only on 'cabal test' invocation. (Con: It does not exists and might be hard to implement :)) Thanks for any help! Regards, Laszlo

3 8

patch applied (cabal): Follow changes in haddock
by Ian Lynagh 05 Jul '09

05 Jul '09

Sun Jul 5 12:36:10 PDT 2009 Ian Lynagh <igloo(a)earth.li> * Follow changes in haddock The --verbose flag is now called --verbosity M ./Distribution/Simple/Haddock.hs -4 +9 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090705193610-3fd76-b32f19d5…

1 0