- cabal-devel - Haskell.org

darcs patch: Add -framework arguments when linking executables
by Judah Jacobson 10 Dec '07

10 Dec '07

I noticed that Cabal isn't passing the -framework option when linking executables with GHC. The attached patch fixes this. Thanks, -Judah * Add -framework arguments when linking executables. M ./Distribution/Simple/GHC.hs +1

1 0

command line flag types are monoids
by Duncan Coutts 09 Dec '07

09 Dec '07

warning: rambling ahead... Perhaps this was obvious to everyone else but I've just come to realise it over the past couple days as I've been doing more refactoring work on Cabal and cabal-install's command line handling. There are basically two kinds of command line flags, ones that represent a singular piece of information like: --enable-foo --disable-foo --enable-foo --disable-foo No matter how many times one uses those kinds of flags, they just set or reset a single piece of information, in this case a boolean. It doesn't just have to be a boolean of course: --user --global --package-db=specific.package.conf is a flag of type PackageDB. Then there are command line flags that represent a set or sequence of information, like: --ghc-option=this --ghc-option=that --ghc-option=theother which represents ["this", "that", "theother"]. Lists are of course also monoids. So we get the list kind of flag monoid for free and the other is the Last monoid. Unfortunately it's only in Data.Monoid as of base-3.0, but it's easy to define a copy: data Flag a = Flag a | Default instance Functor Flag where fmap f (Flag x) = Flag (f x) fmap _ Default = Default instance Monoid (Flag a) where mempty = Default _ `mappend` f@(Flag _) = f f `mappend` Default = f flagOrDefault default (Flag x) = x flagOrDefault default Default = default So a command usually takes a collection of specific kinds of flags. If all of these flags are themselves monoids then the overall collection is also a monoid, defined pointwise: data ConfigFlags = ConfigFlags { foo :: Flag Bool, bar :: Flag PackageDB, baz :: [String] } instance Monoid ConfigFlags where mempty = ConfigFlags mempty mempty mempty a `mappend` b = ConfigFlags (foo a `mappend` foo b) (bar a `mappend` bar b) (baz a `mappend` baz b) This is really useful because it means we can combine flags from several sources, from defaults and override it with command line flags or setting read from config files. The latter is particularly useful for cabal-install which has a config file where users can override defaults. So I'll try converting all the flags types to this Monoid style. Duncan

1 0

patch applied (cabal): Support --hyperlink-source for Haddock >= 2.0
by Duncan Coutts 09 Dec '07

09 Dec '07

Sun Dec 9 10:05:55 PST 2007 David Waern <davve(a)dtek.chalmers.se> * Support --hyperlink-source for Haddock >= 2.0 M ./Distribution/Simple/Haddock.hs -1 +1

1 0

[Hackage] #186: Compiling Paths_<Application> with -Wall produces warnings
by Hackage 07 Dec '07

07 Dec '07

#186: Compiling Paths_<Application> with -Wall produces warnings ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: low | Milestone: Component: Cabal | Version: Severity: minor | Keywords: Difficulty: normal | Ghcversion: 6.6.1 Platform: Linux | ---------------------+------------------------------------------------------ The autogenerated file dist/build/autogen/Paths_<Applicacion>.hs produces type signature warnings if we use -Wall compiler option. Example of output: [1 of 5] Compiling Paths_hsCalc ( dist/build/autogen/Paths_hsCalc.hs, dist/build/hscalc/hscalc-tmp/Paths_hsCalc.o ) dist/build/autogen/Paths_hsCalc.hs:9:0: Warning: Definition but no type signature for `version' dist/build/autogen/Paths_hsCalc.hs:11:0: Warning: Definition but no type signature for `bindir' dist/build/autogen/Paths_hsCalc.hs:12:0: Warning: Definition but no type signature for `libdir' dist/build/autogen/Paths_hsCalc.hs:13:0: Warning: Definition but no type signature for `datadir' dist/build/autogen/Paths_hsCalc.hs:14:0: Warning: Definition but no type signature for `libexecdir' Linking dist/build/hscalc/hscalc ... -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/186> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal): Use a default HsColour CSS if available
by Duncan Coutts 06 Dec '07

06 Dec '07

Thu Dec 6 06:59:37 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Use a default HsColour CSS if available Supported in HsColour 1.9 and later M ./Distribution/Simple/Haddock.hs -8 +11

1 0

patch applied (cabal): export ccLdOptionsBuildInfo helper function
by Duncan Coutts 06 Dec '07

06 Dec '07

Wed Dec 5 11:41:46 PST 2007 Duncan Coutts <duncan(a)haskell.org> * export ccLdOptionsBuildInfo helper function Useful in Setup.hs scripts for things like HSQL that need to find CC and LD flags by calling foo-config style programs. The same function is used internally for pkg-config support. M ./Distribution/PackageDescription.hs +1 M ./Distribution/Simple/Configure.hs -24 +36

1 0

cabal for ghc 6.8.2, package upgrade warnings, please?
by Claus Reinke 04 Dec '07

04 Dec '07

assuming that ghc 6.8.2 is not too far away, is there any chance of cabal becoming a bit friendlier wrt old .cabal and Setup files, before that release? you've heard me say before that i'd have preferred a backwards compatibility module, but if that isn't possible, couldn't cabal at least detect that a .cabal file is probably outdated (==not obviously up to date), and issue a warning with a helpful url? something like: $ runhaskell Setup configure *** warning: this .cabal/Setup file might be out of date; *** if you run into issues, please contact the *** package maintainer, and have a look at *** http://haskell.org/haskellwiki/Upgrading_packages .. (either it works or you get errors here, but you already know something is not quite right, and what to do about it) btw, i knew that page existed, but had quite a bit of trouble finding it. shouldn't there be prominent links to it from cabal and hackage home pages? as in: concerning recent cabal updates (look here first if you have trouble with old .cabal packages). in the longer term, that could become the start of a cabal/hackage faq section.. claus

2 7

Weird error message ('Cannot determine version of GHC')
by Anthony Chaumas-Pellet 02 Dec '07

02 Dec '07

Hello, I've just run across a fairly confusing error message when running 'cabal install': Warning: cannot determine version of /usr/local/bin/ghc : "" cabal: ghc version >=6.2 is required but the version of /usr/local/bin/ghc could not be determined. This error only appears with the install command, apparently when Cabal is run from a directory where it cannot write files (I was under /sys/, but the same goes for e.g. /usr/ as a non-root user). If possible, I think the error message should be clearer (it took me a while to figure out what was going on, and Google had no hits for that error message). I'm running under Debian Unstable, with ghc-6.8.1 and a very recent Cabal Darcs build. Unfortunately, I cannot try reproducing that glitch on the latest Cabal release. Thanks! Anthony

2 1

patch applied (cabal): make rawSystemStdout put its temp files in the temp dir rather than cwd
by Duncan Coutts 02 Dec '07

02 Dec '07

Sun Dec 2 14:06:20 PST 2007 Duncan Coutts <duncan(a)haskell.org> * make rawSystemStdout put its temp files in the temp dir rather than cwd Should fixe reported wierdness with finding program version numbers M ./Distribution/Simple/Utils.hs -2 +4

1 0

patch applied (cabal-branches/cabal-1.2): Bump version to 1.2.3.0 and update the changelog
by Ian Lynagh 01 Dec '07

01 Dec '07

Thu Nov 29 06:39:45 PST 2007 Duncan Coutts <duncan(a)haskell.org> * Bump version to 1.2.3.0 and update the changelog There was one minor api addition which requires the minor version bump M ./Cabal.cabal -2 +2 M ./Makefile -2 +2 M ./changelog -1 +5 M ./releaseNotes -1 +1

1 0