- cabal-devel - Haskell.org

darcs patch: Trac #221 part 1 (and 1 more)
by mnislaih＠gmail.com 16 Mar '08

16 Mar '08

Sun Mar 2 13:50:20 CET 2008 Pepe Iborra <mnislaih#(a)gmial.oail.com> * Trac #221 part 1 This patch adds two missing cl flags to configure, --extra-include-dirs and extra-lib-dirs. These have effect over all the buildables in a project. The next step is to close #223 so that all the configure cl flags can be stored in the .cabal/config file. With this patch, that should close #221 too. Sun Mar 16 17:25:10 CET 2008 Pepe Iborra <mnislaih#(a)gmial.oail.com> * Refactoring Distribution.Command.Simple.Option (see Ticket #223) so that it really represents an option and not just a flag. data Option a = Option { 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]) | Choice [(Description, OptFlags, a->a, a -> Bool)] Now an option can expand to several flags, 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) [] ("disable-optimization": case showOrParseArgs of -- Allow British English spelling: ShowArgs -> []; ParseArgs -> ["disable-optimisation"]) "Build without optimization" ] The benefit is that we can now derive a FieldDescr from an Option, viewAsFieldDescr :: Option a -> FieldDescr a and this allows for easy human readable serialization of Options to a config file, as it is needed for cabal-install.

1 0

darcs patch: Trac #221 part 1 (and 1 more)
by Pepe Iborra 16 Mar '08

16 Mar '08

Sun Mar 2 13:50:20 CET 2008 Pepe Iborra <mnislaih#(a)gmial.oail.com> * Trac #221 part 1 This patch adds two missing cl flags to configure, --extra-include-dirs and extra-lib-dirs. These have effect over all the buildables in a project. The next step is to close #223 so that all the configure cl flags can be stored in the .cabal/config file. With this patch, that should close #221 too. Sat Mar 15 20:12:52 CET 2008 Pepe Iborra <mnislaih#(a)gmial.oail.com> * Refactoring Distribution.Command.Simple.Option (see Ticket #223) so that it really represents an option and not just a flag. data Option a = Option { 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]) | Choice [(Description, OptFlags, a->a, a -> Bool)] Now an option can expand to several flags, 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) [] ("disable-optimization": case showOrParseArgs of -- Allow British English spelling: ShowArgs -> []; ParseArgs -> ["disable-optimisation"]) "Build without optimization" ] The benefit is that we can now derive a FieldDescr from an Option, viewAsFieldDescr :: Option a -> FieldDescr a and this allows for easy human readable serialization of Options to a config file, as it is needed for cabal-install.

1 0

[Hackage] #259: Release ratings
by Hackage 13 Mar '08

13 Mar '08

#259: Release ratings --------------------------------+------------------------------------------- Reporter: SamB | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: HackageDB website | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | --------------------------------+------------------------------------------- It should be possible to rate package releases on quality of release, to motivate competetive uploaders to focus on quality rather than quantity of uploads. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/259> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #161: 'sdist' cannot find some modules that 'build' finds ok
by Hackage 13 Mar '08

13 Mar '08

#161: 'sdist' cannot find some modules that 'build' finds ok ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: closed Priority: high | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Ok, discovered the problem and why the behavior was inconsistent. Turns out it __should__ fail in the `build` step too. The `sdist` was behaving properly and building (or rather pre-processing) should not have found that file. So it turns out that {{{ hs-source-dirs: tests . }}} in the executable section is not just a workaround but the correct thing to do. Let's look at the .cabal file again: {{{ ... snip ... build-depends: base, bytestring, HUnit, network exposed-modules: Network.Socket.ByteString extensions: CPP, ForeignFunctionInterface executable: tests main-is: UnitTests.hs hs-source-dirs: tests other-modules: Network.Socket.ByteString extensions: CPP, ForeignFunctionInterface }}} And we have these files: {{{ Network/SocketByteString.cpphs tests/UnitTests.hs }}} The meaning of `hs-source-dirs` is to look in just those directories for source files. If it is not specified then it defaults to `.` however note that `.` is __not__ added to the list if `hs-source-dirs` is specified explicitly. So it's actually quite right that `Network/SocketByteString.cpphs` is not found for the executable which specifies `hs-source-dirs: tests`. Indeed if we change the file to `Network/SocketByteString.hs` then we'll see that ghc cannot find the file, because we're passing `-i -itests` which means to clear the search path completely and then add `tests` to the search path. So why does it get found when we use a `.cpphs` file rather than a `.hs` file? Well that's the bug. The pre-processing code for executables was combining the search path for the executable with the search path for the library: {{{ nub $ (hsSourceDirs bi) ++ (maybe [] (hsSourceDirs . libBuildInfo) (library pkg_descr))) }}} So the `.cpphs` source file got found and the pre-processed output then goes into a directory that we do tell ghc to look in and that's why it was being found. The consistent thing to do here is to use just `(hsSourceDirs bi)`. (`bi` here refers to the build info for the executable in question). So I think that fixes the inconsistency by bringing pre-processing into line with everything else. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/161#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): Fix search dirs used for pre-processing executables
by Duncan Coutts 13 Mar '08

13 Mar '08

Wed Mar 12 13:39:47 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Fix search dirs used for pre-processing executables It was combining the executable's hs-source-dirs with the library's hs-source-dirs when pre-processing executables. This was inconsistent with the search path used for finding ordinary .hs files and with sdist and lead to confusing behaviour. See ticket #161. If an executable needs source files from the library then it must specify the right hs-source-dirs, including '.' if appropriate. The behaviour is that if hs-source-dirs is not specified then the default is '.' however if hs-source-dirs is specified then '.' is not implicitly added. If it's needed then it must be added explicitly. This was always the case for ordinary .hs files, this patch just brings things into line for files that need pre-processing. M ./Distribution/Simple/PreProcess.hs -6 +4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080312203947-adfee-548dcefa…

1 0

[Hackage] #204: should setting user-prefix in ~/.cabal/config work?
by Hackage 12 Mar '08

12 Mar '08

#204: should setting user-prefix in ~/.cabal/config work? ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ---------------------------------+------------------------------------------ Setting user-prefix in .cabal/config leads to the following error: {{{ wolverian@puni:~$ cabal info xmonad Warning: Error parsing config file /home/wolverian/.cabal/config: On line 5: Parse of field 'prefix' failed: Warning: Using default configuration. }}} I don't think the file format is documented anywhere, but a bit of poking in the source and a Google led me to believe that this should work. My config file looks like this: {{{ wolverian@puni:~$ cat .cabal/config compiler: GHC repos: hackage.haskell.org:http://hackage.haskell.org/packages/archive cachedir: "/home/wolverian/.cabal/packages" user-install: true user-prefix: "/home/wolverian" hackage-username: "" hackage-password: "" }}} This is with up-to-date (as of today) Cabal and cabal-install from Darcs: {{{ wolverian@puni:~$ cabal --version cabal-install version 0.4.1 using version 1.3.2 of the Cabal library }}} And my GHC is a local (in ~) GHC 6.8.2: {{{ wolverian@puni:~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 }}} -- wolverian[[BR]] ilmari.vacklin(a)cs.helsinki.fi -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/204> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

patch applied (cabal-install): Parse filepaths in the config file the same way as in .cabal files
by Duncan Coutts 12 Mar '08

12 Mar '08

Wed Mar 12 06:53:35 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Parse filepaths in the config file the same way as in .cabal files That is, allow quoted and unquoted paths. M ./Hackage/Config.hs -7 +12 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080312135335-adfee-…

1 0

Re: [Hackage] #56: hackageDB should not accept a package if it is not installable
by Hackage 12 Mar '08

12 Mar '08

#56: hackageDB should not accept a package if it is not installable --------------------------------+------------------------------------------- Reporter: ijones | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.6 Component: HackageDB website | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux --------------------------------+------------------------------------------- Changes (by duncan): * milestone: Cabal-1.4 => Cabal-1.6 Comment: Not ready for this release, punting. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/56#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #24: Cabal shouldn't try to build GHCI libs on platforms without GHCI
by Hackage 12 Mar '08

12 Mar '08

#24: Cabal shouldn't try to build GHCI libs on platforms without GHCI ------------------------------------+--------------------------------------- Reporter: jgoerzen(a)complete.org | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.6 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.2.1 | Platform: Linux ------------------------------------+--------------------------------------- Changes (by duncan): * milestone: Cabal-1.4 => Cabal-1.6 Comment: This is pretty easy bug but it does not seem to bother anybody enough to fix it or even comment on it. Punting. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/24#comment:7> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #205: Remove BSD4 from Cabal.Distribution.License.License
by Hackage 12 Mar '08

12 Mar '08

#205: Remove BSD4 from Cabal.Distribution.License.License ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: Linux | ----------------------------+----------------------------------------------- I doubt any Haskell software actually uses the BSD4 license, and it is likely to confuse users as it looks like a newer version of BSD3. Currently we have {{{ data License = ... | BSD3 | BSD4 }}} so I propose moving to one of {{{ data License = ... | BSD3 data License = ... | BSD data License = ... | BSD3 | OldBSD data License = ... | BSD | OldBSD data License = ... | NewBSD | OldBSD }}} (http://www.opensource.org/licenses/alphabetical lists it as "New BSD license") All but the first will require changing a number of packages. We could leave the old BSD3 name as deprecated for a while, though. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/205> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4