- cabal-devel - Haskell.org

patch applied (cabal): Document the --extra-include-dirs and --extra-lib-dirs options
by Duncan Coutts 18 Mar '08

18 Mar '08

Tue Mar 18 06:49:13 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Document the --extra-include-dirs and --extra-lib-dirs options Though they actually only take one dir each so perhaps they should be renamed to just --extra-include-dir and --extra-lib-dir. You can of course use them multiple times to get a list of dirs. M ./doc/Cabal.xml +50 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080318134913-adfee-3bc31a0d…

1 0

[Hackage] #221: a generic way for cabal-install to specify external dependencies
by Hackage 18 Mar '08

18 Mar '08

#221: a generic way for cabal-install to specify external dependencies ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ----------------------------+----------------------------------------------- Cabal-install needs a way to specify external dependencies, so that re- install can be made as automatic as possible. The fact that Cabal records the 3rd digit version in the path indicates a diligent user has to re- install all the packages on every new 3rd-digit dot release. Exanples are HDBC-ODBC and regex-pcre. This issue was raised in http://www.mail-archive.com/haskell-cafe@haskell.org/msg37001.html It was discussed before and Tim had one suggestion: http://www.mail-archive.com/haskell-cafe@haskell.org/msg33790.html I suggest to have a config-replacement file (or a section in .cabal/config) as such: package: SDL include-dirs: c:\libs\SDL\include When cabal-install attempts to install SDL in this case, it will replace the line "include-dirs" in <package>.cabal with what is suggested in the config-replacement file. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/221> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 7

forwards compatability in enumerations in .cabal files
by Duncan Coutts 18 Mar '08

18 Mar '08

I'm looking for some advice... I think lots of bits of the current parser need another look. All the enumeration fields are very brittle and do not allow for any forwards compatibility. Cabal's current response to adding a new compiler, license, build-type, language extension or whatever is to just fail with a "parse error in field 'foo' on line N". All uses of parseReadS really have to go. One idea is to add an extra catch-all onto these enums, like: data CompilerFlavour = ... | UnknownCompiler String then we check for such unknown values and warn about them and do not allow them to be uploaded to hackage. When we add new enum values, older Cabal versions will treat the value as other/unknown and where possible carry on with just a warning. Where it's not possible to carry on with an unknown value it can fail with a more helpful error message. Another alternative is to keep only known values in the enumeration but do something more generic in the parser to represent unknown or failed values. However that still leaves the problem of what to do when we encounter unknown values. How they're handled really depends on the type. New compilers or OSs mentioned in configurations are ok, where as new build-types cannot be handled. Any other suggestions? One way or another I think the plan for Cabal 1.4 should be to make the parser for these things more liberal but not to accept any new values so that we do not break older Cabal versions by adding .cabal files to hackage that older Cabal cannot parse. When enough time has passed and the current Cabal-1.4 and later are the norm, it'll be possible to add new enum values without causing major breakage. Duncan

1 0

patch applied (cabal): Use the same ReadP for all compilers, remove CPP hacks
by Duncan Coutts 18 Mar '08

18 Mar '08

Mon Mar 10 12:14:22 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Use the same ReadP for all compilers, remove CPP hacks If we're bundling a whole copy of ReadP then why bother trying to use the version from the base package, especially when that requires hacks to use the H98 version with some compilers and the non-H98 version in base. It just makes testing harder because we're using different versions with different compilers. As a bonus, hugs should no longer need the -98 flag to use Cabal. Added all the type signatures back in and fixed some warnings. M ./Distribution/Compat/ReadP.hs -58 +42 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080310191422-adfee-0d58dbdd…

2 3

patch applied (cabal): #221: specific include and library search paths options
by Duncan Coutts 18 Mar '08

18 Mar '08

Mon Mar 17 11:12:03 PDT 2008 Pepe Iborra <mnislaih(a)gmail.com> * #221: specific include and library search paths options This patch adds two new command line options to configure, --extra-include-dirs and extra-lib-dirs. These have effect over all the buildables in a project. What is missing now is support for reading these from the .cabal/config file. That will be done as part of ticket #223. M ./Distribution/Simple/Configure.hs -4 +14 M ./Distribution/Simple/Setup.hs +15 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080317181203-ddd76-727101bd…

1 0

darcs patch: #221: specific include and library searc... (and 1 more)
by Pepe Iborra 17 Mar '08

17 Mar '08

Mon Mar 17 19:12:03 CET 2008 Pepe Iborra <mnislaih(a)gmail.com> * #221: specific include and library search paths options This patch adds two new command line options to configure, --extra-include-dirs and extra-lib-dirs. These have effect over all the buildables in a project. What is missing now is support for reading these from the .cabal/config file. That will be done as part of ticket #223. Mon Mar 17 21:30:15 CET 2008 Pepe Iborra <mnislaih(a)gmail.com> * #223 part 1: Extend Distribution.Command.Simple.Option so that it really represents an option and not just a flag. It's been renamed to OptionField as it models a field in a flags-like data structure. data OptionField a = OptionField { optionName :: Name, optionDescr :: [OptDescr a] } data OptDescr a = ReqArg Description OptFlags ArgDescr (ReadE (a->a)) (a -> [String]) | OptArg Description OptFlags ArgDescr (ReadE (a->a)) (a->a) (a -> [Maybe String]) | ChoiceOpt [(Description, OptFlags, a->a, a -> Bool)] | BoolOpt Description OptFlags{-True-} OptFlags{-False-} (Bool -> a -> a) (a -> Bool) An option field can expand to several command line options, which are all defined together. For example, the compiler flag is defined as follows. option [] ["compiler"] "compiler" configHcFlavor (\v flags -> flags { configHcFlavor = v }) (choiceOpt [ (Flag GHC, ("g", ["ghc"]), "compile with GHC") , (Flag NHC, ([] , ["nhc98"]), "compile with NHC") , (Flag JHC, ([] , ["jhc"]), "compile with JHC") , (Flag Hugs,([] , ["hugs"]), "compile with Hugs")]) We can need to use several kinds of OptDescr for the same option, as in the optimization Option (really a extreme case): ,multiOption "optimization" configOptimization (\v flags -> flags { configOptimization = v }) [optArg' "n" (Flag . flagToOptimisationLevel) .... .... "Build with optimization (n is 0--2, default is 1)", noArg (Flag NoOptimisation) []

1 0

Re: [Hackage] #88: Stripping
by Hackage 17 Mar '08

17 Mar '08

#88: Stripping ---------------------------------+------------------------------------------ Reporter: bjorn(a)bringert.net | Owner: Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.4 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: very easy (<1 hour) Ghcversion: 6.4.2 | Platform: ---------------------------------+------------------------------------------ Changes (by duncan): * difficulty: normal => very easy (<1 hour) Comment: Partly done: {{{ Mon Mar 17 19:32:14 GMT 2008 Duncan Coutts <duncan(a)haskell.org> * Strip executables during installation for ghc Does not yet have a configure flag to turn this behaviour on and off. That can wait until after the command line flag infrastructure changes. }}} As the commit message says, we still need to add a command line flag to enable/disable. It'll be enabled by default but we do need to make it possible to disable if for no other reason than some distros prefer to handle stripping themselves. The flag will be a configure flag `--enable/disable-executable-stripping`. The rationale for it being a configure rather than install flag is that we would in any case need it as a flag for `cabal-install`'s `install` command, which takes all the flags for the underlying `configure` command. It'll also need documenting. Once the command line changes are done, the remaining task is easy. Marking as such. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/88#comment:7> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): Move the call to ranlib out into a separate function
by Duncan Coutts 17 Mar '08

17 Mar '08

Mon Mar 17 12:32:58 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Move the call to ranlib out into a separate function It's a bit more readable that way. M ./Distribution/Simple/GHC.hs -13 +17 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080317193258-adfee-7a424b1e…

1 0

patch applied (cabal): Strip executables during installation for ghc
by Duncan Coutts 17 Mar '08

17 Mar '08

Mon Mar 17 12:32:14 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Strip executables during installation for ghc Does not yet have a configure flag to turn this behaviour on and off. That can wait until after the command line flag infrastructure changes. M ./Distribution/Simple/GHC.hs -10 +17 M ./Distribution/Simple/Install.hs -1 +1 M ./Distribution/Simple/Program.hs +5 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080317193214-adfee-17c2cc53…

1 0

patch applied (cabal): Add a CompilerId type and use it in appropriate places
by Duncan Coutts 17 Mar '08

17 Mar '08

Tue Mar 11 20:12:47 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add a CompilerId type and use it in appropriate places Especially instead of abusing a PackageIdentifier for the purpose. M ./Distribution/Compiler.hs -1 +19 M ./Distribution/Simple/Build.hs -1 +2 M ./Distribution/Simple/BuildPaths.hs -4 +7 M ./Distribution/Simple/Compiler.hs -8 +10 M ./Distribution/Simple/Configure.hs -2 +2 M ./Distribution/Simple/GHC.hs -3 +4 M ./Distribution/Simple/Hugs.hs -4 +3 M ./Distribution/Simple/Install.hs -1 +2 M ./Distribution/Simple/InstallDirs.hs -6 +7 M ./Distribution/Simple/JHC.hs -6 +5 M ./Distribution/Simple/NHC.hs -4 +4 M ./Distribution/Simple/PreProcess.hs -1 +2 M ./Distribution/Simple/Register.hs -2 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080312031247-adfee-fc0c3c98…

1 0