- cabal-devel - Haskell.org

patch applied (cabal-install): Add warnings in the case that no remote servers have been specified
by Duncan Coutts 16 Feb '09

16 Feb '09

Mon Feb 16 10:14:24 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Add warnings in the case that no remote servers have been specified It's not strictly an error but it can be rather confusing. M ./Distribution/Client/IndexUtils.hs +7 M ./Distribution/Client/Update.hs -1 +4 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090216181424-adfee-…

1 0

[Hackage] #493: counterintuitive syntax of .cabal/config file
by Hackage 16 Feb '09

16 Feb '09

#493: counterintuitive syntax of .cabal/config file ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ I wanted to change the default so that profiling libraries were always built. So I edited the ~/.cabal/config file as follows: OLD: {{{ -- library-vanilla: True -- library-profiling: False -- shared: False }}} NEW: {{{ -- library-vanilla: True library-profiling: True -- shared: False }}} I assumed that the --'s were Haskell comment syntax and indicated defaults, and that by removing them I could change an option. This didn't work. After a while I discovered that I had to do it this way: NEW, Version 2: {{{ -- library-vanilla: True library-profiling: True -- shared: False }}} This time it worked. But this wouldn't have been my first guess from looking at the config file, and I didn't find anywhere to look for documentation on the config file's format. (It would be helpful if this were available as an option in 'cabal help'. Maybe it is, and I didn't see it?) cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/493> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #501: clean up UI for build logging / reporting
by Hackage 16 Feb '09

16 Feb '09

#501: clean up UI for build logging / reporting ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ---------------------------------+------------------------------------------ The current `cabal install` command line interface to specify build logs files is incomplete and a bit confusing. The current interface is: {{{ --log-builds=FILE Log all builds to file (name template can use $pkgid, $compiler, $os, $arch) --build-reports Generate detailed build reports. (overrides --log-builds) }}} However we also always generate a local build summary to `~/.cabal/logs/build.log` and a anonymous remote one in `~/.cabal/packages/$server/build-reports.log`. The generation of these is not controllable at the moment. While the underlying mechanisms are similar, we think it is useful in the user interface to separate the local logging from the generation of build reports to send to remote hackage servers. There are two aspects to local logging. We can generate machine readable summary information like: {{{ package: xmonad-0.7 os: linux arch: x86_64 compiler: ghc-6.8.2 client: cabal-install-0.5.2 flags: -testing small_base dependencies: X11-1.4.2 base-3.0.1.0 containers-0.1.0.1 directory-1.0.0.0 mtl-1.1.0.0 process-1.0.0.0 unix-2.3.0.0 install-outcome: InstallOk docs-outcome: NotTried tests-outcome: NotTried }}} and we can generate the actual build log. So we propose controlling each separately with the flags: {{{ --local-build-summary=FILE --local-build-log=FILE }}} The `FILE` parameter can contain instances of variables like '$pkgid' etc to allow for splitting the summaries or logs into different files. Each log/summary file is written using file append so it should be possible to have both go into one file (interleaved). For the remote case the layout of the files is prescribed. The user has no control over that. They should just be able to specify the level of logging. We suggest: {{{ --remote-build-reporting=[none,anonymous,detailed] }}} A couple remaining questions: * how to specify that we do not want any local summary, not even the default one * does `--local-build-summary=` specify a single valued configuration setting or a list? If I specify it multiple times, does it write into all files or only the last? One possible answer to the above is to say that it's a list of files and the default is given in the `~/.cabal/config` file. So adding `--local- build-summary=` would write into both the default and the extra file. That way if someone really wants to they can turn off the default log. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/501> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal-install): Put an explanation of the config file format at the top in comments.
by Duncan Coutts 16 Feb '09

16 Feb '09

Sun Feb 15 11:08:17 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Put an explanation of the config file format at the top in comments. M ./Distribution/Client/Config.hs -1 +13 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090215190817-adfee-…

1 0

patch applied (cabal-install): Change the field order in the initial config file.
by Duncan Coutts 16 Feb '09

16 Feb '09

Sun Feb 15 11:07:27 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Change the field order in the initial config file. Also update the name of one excluded field. M ./Distribution/Client/Config.hs -19 +22 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090215190727-adfee-…

1 0

patch applied (cabal-install): Put the default logging and reporting setting in the initial config file.
by Duncan Coutts 16 Feb '09

16 Feb '09

Sun Feb 15 11:05:24 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Put the default logging and reporting setting in the initial config file. M ./Distribution/Client/Config.hs +7 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090215190524-adfee-…

1 0

patch applied (cabal-install): Complete the implementation of --build-summary=TEMPLATE
by Duncan Coutts 16 Feb '09

16 Feb '09

Sun Feb 15 11:02:54 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Complete the implementation of --build-summary=TEMPLATE Actually respect the new flag. It's actually a list of template files and all specified files get written to. This allows us to specify a default build log file and also have the user write to extra ones. The summary file template can contain $pkgid $compiler etc. M ./Distribution/Client/BuildReports/Storage.hs -12 +25 M ./Distribution/Client/Install.hs -4 +6 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090215190254-adfee-…

1 0

patch applied (cabal-install): Rearrange user interface for build logging
by Duncan Coutts 16 Feb '09

16 Feb '09

Sun Feb 15 10:58:00 PST 2009 Duncan Coutts <duncan(a)haskell.org> * Rearrange user interface for build logging The new options (as described in ticket #501) are: --build-summary=TEMPLATE --build-log=TEMPLATE --remote-build-reporting=LEVEL where LELVEL `elem` [none,anonymous,detailed] A ./Distribution/Client/BuildReports/Types.hs M ./Distribution/Client/Install.hs -9 +14 M ./Distribution/Client/Setup.hs -8 +25 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20090215185800-adfee-…

1 0

darcs patch: Add flag to disable linking in build
by hamish＠firestream.co.uk 15 Feb '09

15 Feb '09

Mon Feb 16 03:46:40 NZDT 2009 hamish(a)firestream.co.uk * Add flag to disable linking in build This is usefull when you just want to find compiler errors (eg. for background compilation while editing). Only implemented for GHC (others will die with an error if linking is disabled).

1 0

[Hackage] #500: develop a tool to find the maximal consistent set of hackage packages
by Hackage 15 Feb '09

15 Feb '09

#500: develop a tool to find the maximal consistent set of hackage packages ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: miscellaneous | Version: Severity: normal | Keywords: Difficulty: project(> week) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- To a great extent the point of libraries is code re-use. It follows that is it useful to be able to install and use two packages simultaneously. The extension of this is that we would like to know the maximal set of packages that we can install consistently. Them being consistent implies that we can use any of them in another package and have consistent dependencies. If we knew a package was within the maximal subset then we can give it a positive mark on hackage. We may also be able to encourage package authors to update their dependencies to as to get their packages within this set. Calculating the maximal consistent subset is certainly an NP-complete problem. It is at least as hard as working out if any single package is installable and that is already NP-complete. However we do not necessarily have to get an exact maximal set, approximation would probably do. We would also like to influence the choice of the set by the importance of packages, especially when it comes to resolving choices about divisive packages (see #499). We would also like to influence the choices by manually supplied preferences. This can probably be implemented as an extension of the standard package dependency resolution algorithm and using the code developed for ticket #499. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/500> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5