- cabal-devel - Haskell.org

[Hackage] #444: Simple builds ignore .buildinfo
by Hackage 07 Jan '09

07 Jan '09

#444: Simple builds ignore .buildinfo ----------------------------+----------------------------------------------- Reporter: awick | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- It would be convenient if Simple builds would look for buildinfo files, instead of just ignoring them. It's sometimes convenient to have the configure script run as a separate phase (for example, when you're configuring a bunch of separate cabal packages) instead of re-running the same configure tests every time, and this would help. There's an obvious workaround (setting the type to 'Configure' and then adding an empty 'configure' script), but this is tedious. I've attached a simple example. The .buildinfo file tells Cabal to build Test2 in addition to Test1. If you set the type to Simple, it only builds Test1. If you set it to 'Configure', it runs the empty configure script and then builds both Test1 and Test2. It'd be nicer if 'Simple' caused both Test1 and Test2 to be built, as well. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/444> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #441: cabal update does not update dependent components
by Hackage 07 Jan '09

07 Jan '09

#441: cabal update does not update dependent components ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ When I run `cabal update` it updates one-or-more package(s). But does not rebuild/reinstall dependent packages. It must be done manually. I think it would be part of the job. (As I saw it in the ''gentoo world''. :)) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/441> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #440: cabal update ignores configured haddock
by Hackage 07 Jan '09

07 Jan '09

#440: cabal update ignores configured haddock ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ When I run `cabal update` it refresh the packages, but does not generate the haddock documentation. This is what i have in the {{{~/.cabal/config}}} file: {{{ .. documentation: True }}} This is what i got in the {{{~/.cabal/packages/hackage.haskell.org/build- reports.log}}} file: {{{ .. install-outcome: InstallOk docs-outcome: NotTried }}} If I rerun the `cabal install <pkg> --reinstall` command, it generates the documentation right. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/440> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #342: Allow automatic resolving of conditionals on more than just build-depends
by Hackage 07 Jan '09

07 Jan '09

#342: Allow automatic resolving of conditionals on more than just build-depends -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | -----------------------------+---------------------------------------------- We have several classes of dependency that we can express in .cabal files. The most obvious is other Haskell packages via the `build-depends` field. The others are: * C libs (`extra-libraries`) * C headers (`includes`) * other build tools (`build-tools`) * pkg-config packages (`pkgconfig-depends`) * MacOS X frameworks (`frameworks`) And we may end up with more, like Windows assemblies. If we know (by domain-specific means) what dependencies are available then we should be able to automatically resolve flag conditions that depend on them. So each one is it's own namespace and they have different representations of keys. Most use a name and some a version too. Currently `finalizePackageDescription` takes a `Maybe (PackageSet pkg)` as a way of testing if deps are available. We should generalise this to a dep testing function (which is essentially what `finalizePackageDescription` turns it into internally) on a type that has alternatives for each of the dependency namespaces. If we only had to generalise it for package constraints we might go for `Dependency -> [PackageId]` but how should we do it when we have multiple namespaces and some require version constraints and others do not. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/342> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

[Hackage] #443: remove package
by Hackage 05 Jan '09

05 Jan '09

#443: remove package ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ Remove package now is a handy work. (Register out from ghc-pkg and remove the files.) I expect a `cabal uninstall` command, which might warn me if a dependent package is still on the machine. (Just mention one advantage of not make it by hand.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/443> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal): Ban ghc-options: --make
by Duncan Coutts 23 Dec '08

23 Dec '08

Tue Dec 23 09:06:21 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Ban ghc-options: --make I dunno, some people... M ./Distribution/PackageDescription/Check.hs +4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20081223170621-adfee-be8bef41…

1 0

patch applied (cabal): Update changelog for 1.6.0.2 release
by Duncan Coutts 23 Dec '08

23 Dec '08

Thu Dec 11 06:22:02 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Update changelog for 1.6.0.2 release M ./changelog +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20081211142202-adfee-b98a0c2b…

1 0

patch applied (cabal): Make the compiler PackageDB stuff more flexible
by Duncan Coutts 23 Dec '08

23 Dec '08

Thu Dec 11 06:16:49 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Make the compiler PackageDB stuff more flexible We support using multiple package dbs, however the method for specifying them is very limited. We specify a single package db and that implicitly specifies any other needed dbs. For example the user or a specific db require the global db too. We now represent that stack explicitly. The user interface still uses the single value method and we convert internally. M ./Distribution/Simple/Compiler.hs +20 M ./Distribution/Simple/Configure.hs -8 +19 M ./Distribution/Simple/GHC.hs -6 +12 M ./Distribution/Simple/JHC.hs -3 +7 M ./Distribution/Simple/LHC.hs -8 +21 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20081211141649-adfee-e37bf8bd…

1 0

[Hackage] #387: `cabal check` does not complain about incorrect `Cabal-Version` field
by Hackage 23 Dec '08

23 Dec '08

#387: `cabal check` does not complain about incorrect `Cabal-Version` field ----------------------------+----------------------------------------------- Reporter: Deewiant | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.10.1 Platform: | ----------------------------+----------------------------------------------- The validity of the `Cabal-Version` field is not verified in any way, making it all too easy to accidentally use a feature which isn't actually present in all the versions of Cabal the field allows. Sounds like something `cabal check` should do. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/387> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

[Hackage] #376: Allow constraint on using installed package versions
by Hackage 22 Dec '08

22 Dec '08

#376: Allow constraint on using installed package versions ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ---------------------------------+------------------------------------------ We allow command line args for adding version constraints. Internally the dependency resolver can use constraints on the installed status. We should allow such constraints to be given on the command line, and possibly in the cabal config file. We should probably also allow preferences to be given on the command line too. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/376> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5