- cabal-devel - Haskell.org

[Hackage] #327: should require minimum c2hs version of 0.15
by Hackage 22 Dec '08

22 Dec '08

#327: should require minimum c2hs version of 0.15 ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- Cabal does not work with c2hs older than 0.15. With older c2hs versions the .hs file ends up in the wrong location in the build tree. If we find that c2hs is needed for the build then we should check that it meets this minimum version. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/327> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #383: Hsc2hs preprocessor does not ensure that gcc has been found.
by Hackage 22 Dec '08

22 Dec '08

#383: Hsc2hs preprocessor does not ensure that gcc has been found. ----------------------------+----------------------------------------------- Reporter: nominolo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ----------------------------+----------------------------------------------- When trying to configure with an inplace GHC on Windows, Cabal dies with an irrefutable pattern match error. The offending line is: {{{ Just gccProg = lookupProgram gccProgram (withPrograms lbi) }}} in {{{D.S.PreProcess.ppHsc2hs}}}. The problem was that configure didn't find gcc in its expected place ({{{ghcBase </> "gcc.exe"}}}) and Cabal didn't check that it did before running the preprocessor. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/383> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Warning: Unknown extensions: ViewPatterns
by Neil Mitchell 22 Dec '08

22 Dec '08

Hi It appears cabal doesn't know ViewPatterns are a valid extension: hlint$ cabal install --global Resolving dependencies... Configuring hlint-1.0.0.1... Warning: Unknown extensions: ViewPatterns Preprocessing executables for hlint-1.0.0.1... Building hlint-1.0.0.1... Thanks Neil

2 1

Wildcard syntax
by Neil Mitchell 22 Dec '08

22 Dec '08

Hi, I have base == 4.0.* in my hlint cabal file (http://www.cs.york.ac.uk/fp/darcs/hlint/hlint.cabal) Does that require Cabal 1.4 or 1.6? Apparently 1.2 fails to parse it, but with a cabal-version >= 1.2 declaration I don't get any warnings from Cabal 1.6. So what is the minimum verison for the version wildcard, and why doesn't cabal warn me I got it wrong? Thanks Neil

2 1

patch applied (cabal-install): Respect the --package-db flag when compiling Setup.hs
by Duncan Coutts 21 Dec '08

21 Dec '08

Sun Dec 21 10:47:55 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Respect the --package-db flag when compiling Setup.hs Fixes ticket #394. M ./Distribution/Client/Install.hs -1 +9 M ./Distribution/Client/SetupWrapper.hs -3 +10 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20081221184755-adfee-…

1 0

[Hackage] #394: --package-db flag is not respected for compiling Setup.hs
by Hackage 21 Dec '08

21 Dec '08

#394: --package-db flag is not respected for compiling Setup.hs ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.6 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.3 Platform: | ------------------------------+--------------------------------------------- The `--package-db` flag is used to look for installed packages when building packages, however it does not get used when trying to build a custom `Setup.hs` file. It should be. It's handy to be able to use a completely separate package db to be able to say test multiple versions of the Cabal lib and cabal-install separately but in parallel. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/394> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #437: generalise the package db settings and flags
by Hackage 21 Dec '08

21 Dec '08

#437: generalise the package db settings and flags ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- Currently the user has just one knob to turn to select which package databases to use. This is not enough control. In general we can use a whole stack of package dbs to look for dependent packages and we can use at most one package db to register a package into. If we use a whole stack then it seems sensible that the destination package db be the top one. So we should generalise the setting from a single value to a list of package dbs. There are some constraints for example the global package db generally cannot be omitted and has to be first. Currently we have the flags `--global`, `--user` and `--package-db`. The global and user flags affect several settings. They select the default install prefix and which package db to use. The `--package-db` flag overrides the choice of package db. Of course the user and specific db choices are taken to be on top of the global db. It seems sensible to leave the user and global flags as kind of general policy flags that affect the defaults of other things in one convenient way. The `--global` flag in isolation would correspond to the db stack `[GlobalPackageDB]`. The `--user` flag would correspond to `[GlobalPackageDB, UserPackageDB]`, though perhaps only if the user does not specify any other specific dbs. So here's a proposal: * `--package-db=package.conf.local` appends that db to the stack * The special values `--package-db=$global` and `--package-db=$global` correspond to those package dbs. * The db stack is always taken to be prefixed with the global one. * If the db stack would be empty and the `--user` flag is used then the stack includes the user db. So it's absent if any `--package-db` flag is given and would have to be added explicitly using `--package-db=$user`. It may be useful to have a `--package-dbs` flag that sets several dbs in one go to use with `--package-dbs=$GHC_PACKAGE_PATH`. See #335. However note that ghc considers `$GHC_PACKAGE_PATH` in the search path style where an earlier path overrides later where as we typically have later flags override earlier ones. Examples: * `--global` == `[GlobalPackageDB]` * `--user` == `[GlobalPackageDB, UserPackageDB]` * `--user --package-db=foo` == `[GlobalPackageDB, SpecificPackageDB "foo"]` * `--user --package-db=$user --package-db=foo` == `[GlobalPackageDB, UserPackageDB, SpecificPackageDB "foo"]` If people find this confusing that `--package-db` automatically overrides `--user` then we would instead need a way of undoing the effect of `--user` so that people can get the stack `[GlobalPackageDB, SpecificPackageDB "foo"]` while in other respects doing using an ordinary per-user install. I should note that `--user --package-db=foo` currently does mean `[GlobalPackageDB, SpecificPackageDB "foo"]` and not `[GlobalPackageDB, UserPackageDB, SpecificPackageDB "foo"]` -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/437> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal-install): Use a more precise package substitution test in improvePlan
by Duncan Coutts 19 Dec '08

19 Dec '08

Fri Dec 19 13:59:22 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Use a more precise package substitution test in improvePlan This is where we take a valid plan and we "improve" it by swapping installed packages for available packages wherever possible. This change is to the condition we use in deciding if it is safe to use the installed package in place of a reinstall. Previously we checked that the dependencies of the installed version were exactly the same as the dependencies we were planning to reinstall with. That was valid but rather conservative. It caused problems in some situations where the installed package did not exactly match the available package (eg when using development versions of a package or of ghc). What we do now is test if the extra constraints implied by selecting the installed version are consistent with the existing set of constraints. This involves threading the constraint set around. In theory this should even cope with adding additional packages to the plan as a result of selecting an installed package. M ./Distribution/Client/Dependency/TopDown.hs -19 +47 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20081219215922-adfee-…

1 0

patch applied (cabal-install): Use installed constraints instead of hiding versions of the base package
by Duncan Coutts 19 Dec '08

19 Dec '08

Fri Dec 19 11:37:40 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Use installed constraints instead of hiding versions of the base package We want to stop cabal-install from accidentally trying to upgrade the base package since this doesn't work in most cases. We used to achieve that by deleting the base package from the available package index. We now do it by leaving the package index as is and instead adding a constraint that we pick only an installed version of base. This is a nicer hack and has the potential to give better error messages. M ./Distribution/Client/Dependency.hs -15 +9 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20081219193740-adfee-…

1 0

patch applied (cabal-install): Extend the invariant on the Constraints ADT
by Duncan Coutts 19 Dec '08

19 Dec '08

Fri Dec 19 11:23:09 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Extend the invariant on the Constraints ADT It now carries around the original version of the database purely so that it can do a much more extensive consistency check. Packages are never gained or lost, just transfered between pots in various slightly tricky ways. M ./Distribution/Client/Dependency/TopDown/Constraints.hs -19 +61 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20081219192309-adfee-…

1 0