October 2010 - cabal-devel

Re: Next steps for "cabal test" feature
by Duncan Coutts 17 Feb '11

17 Feb '11

On Mon, 2010-10-11 at 09:51 +0100, Max Bolingbroke wrote: > Sorry I haven't had a chance to review the test API yet, but I have a > good excuse - I was getting ready for my marriage yesterday :-) Perhaps the best excuse I've ever heard :-). Congratulations! > I'll see if I can do a review of the "detailed" interface this week. This week?! Don't you have better things to do? But yes, a review at some point would be appreciated. The goal is to have something close to what test-framework has always had (ie tree of tests, QC, HUnit, other tests to be lifted in) but using as few language extensions as we can get away with. I also rather like Thomas' pure/impure distinction. It's also important of course to handle things like RNG seeds so that we can reproduce test runs. Duncan

4 7

[Hackage] #722: Data-Files cabal directive should support directories
by Hackage 31 Jan '11

31 Jan '11

#722: Data-Files cabal directive should support directories ----------------------------+----------------------------------------------- Reporter: cygnus | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Keywords: recursive directories data sdist Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- It should be possible to use the `Data-Files` directive to include whole directories (recursively) in source distributions. In many cases it's impossible or cumbersome to list all of the files one would like to install, and it seems to me that nobody should have to do that if what they really mean is, "install everything in that-data-dir/." In implementation terms, this doesn't strike me as too tricky; after the wildcard parsing that already happens, detect whether the files to be copied are in fact directories and copy them recursively as such. I'm more than willing to hack on this. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/722> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

Exposure of synopsis in InstalledPackageInfo
by Andy Gimblett 31 Jan '11

31 Jan '11

Hi all, Distribution.PackageDescription.PackageDescription contains the synopsis field, giving a one-line summary of a package's contents. Distribution.InstalledPackageInfo.InstalledPackageInfo, however, doesn't contain this field - just the description. Would it be difficult to expose synopsis in InstalledPackageInfo as well? Rationale: I've written a script which queries the package databases for all installed packages, and builds an HTML page indexing them by package name, with links to local docs (for all versions of the package) and hackage; it's a sort of complement to the by-module index already produced. I'd like to include the synopsis for each module, but pulling it out of the haddock docs (the only solution I can see at the moment) feels clumsy given that all the rest of my info is coming from the Cabal library. Thanks, -Andy -- Andy Gimblett http://gimbo.org.uk/

2 1

[Hackage] #752: sdist not setting the executable bit on the configure script when Build-Type is Configure
by Hackage 17 Jan '11

17 Jan '11

#752: sdist not setting the executable bit on the configure script when Build- Type is Configure ----------------------------+----------------------------------------------- Reporter: pwan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.6 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: 6.12.1 Platform: Linux | ----------------------------+----------------------------------------------- I have a project with Build-Type of Configure. I have a Makefile and configure script set in the Extra-File-Sources portion of the cabal file. The script has its executable bits set. However, when I do a 'runghc Setup.hs sdist', the executable bits from the configure script are lost. This is keeping folks from being able to do the normal 'tar zxvf project.gz ; ./configure ; make'. steps when building from the sdist. The attached file is a patch to SrcDist.hs where prepareTree checks the extra source files for the configure script, and either copies it as an executable or complains about it not being present if the package build type is Configure. I apologize in advance for what is surely horrible noobie code -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/752> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #744: cabal-install depends on time library 1.1.*, whereas 1.2 is default
by Hackage 08 Dec '10

08 Dec '10

#744: cabal-install depends on time library 1.1.*, whereas 1.2 is default ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: 6.10.4 Platform: Linux | ----------------------------------+----------------------------------------- Building cabal-install worked fine for me with the latest version of the time library: 1.2.0.3. I suggest removing the requirement '&& < 1.2' for the time library in cabal-install.cabal. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/744> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

patch: pretty printing for Cabal
by Jürgen Nicklisch-Franken 15 Nov '10

15 Nov '10

I did send this mail a week ago or so to the haskell-libraries mailing list, but this was probably the wrong list. I have in the meantime tested with all cabbal files on haddock, and have fixed some issues. This patch adds a pretty printer for GenericPackageDescription. It fixes ticket http://hackage.haskell.org/trac/hackage/ticket/647. I added a new module Distribution.PackageDescription.PrettyPrint which exports writeGenericPackageDescription and showGenericPackageDescription. I use the field printers from Parse.hs, so that I had to add export statements for them in Distribution.PackageDescription.Parse. I decided to not use a class based approach because: 1. their is already the Text class, which has a parse I didn't want to write, and 2. and more important, I didn't want to use -XFlexibleInstances because I guess cabal should be portable. I have not removed the old printer code, although this may be a good idea (maybe mark it as deprecated first). Then it would make sense as well to rename writeGenericPackageDescription to writePackageDescription and showGenericPackageDescription to showPackageDescription, to be symmetric. I tested with the code from Appendix 1 and all the cabal files on hackage. The test succeds when writing and reading a package description results in an equal description. This is more rigorous then required, cause different GenericPackageDescr.. can have the same semantic, so for example the order of exe definitions is not relevant. But for our needs (GUI editor of cabal files for leksah), e.g. preserving of order is important and it will help to test the parser and printer to make this approach work. Furthermore I want to print out the cabal file as short as possible, e.g. not printing all empty fields like the old printer did. Testing the code I found the following problems: 1. Found up an obvious "age old" bug: hunk ./Distribution/PackageDescription/Parse.hs 359 - ghcProfOptions (\val binfo -> binfo{ghcSharedOptions=val}) + ghcSharedOptions (\val binfo -> binfo{ghcSharedOptions=val}) 2. The order of elements are reversed by the parser. E.g executables: (repos, flags, lib, exes, tests) <- getBody return (repos, flags, lib, exes ++ [(exename, flds)], tests) since the rest is parsed in the line before, the element needs to be prepended. so I changed to: (repos, flags, lib, exes, tests) <- getBody return (repos, flags, lib, (exename, flds): exes, tests) The same applies to test fields. The opposite order problem applies to storeXFields.., which is called in the order of processing, so I changed it to storeXFieldsPD (f@('x':'-':_),val) pkg = Just pkg{ customFieldsPD = (customFieldsPD pkg) ++ [(f,val)]} 3. The next problem is that we print nothing for empty fields , which works ok, except for compiler opts, where empty opts differ from not given opts, so I added this line to optsField in ParseUtils, which causes empty opts to be parsed, as if no opts are given: update f opts [] = [(f,opts)] 4. The next problem is that we loose final newlines with showFreeText. Astonishing enough the culpid is lines from the List module , which evals lines "a\n" to ["a"]. By the way even the claim that "'unlines' is an inverse operation to 'lines'" from the List module is not true, as unlines (lines "a") -> "a\n" (see Appendix 2). So I use my own unlines' now!. 5. This is connected to the CondTree structure. When I write a Cabl file like: ... library extensions: ForeignFunctionInterface if flag(use_xft) build-depends: X11-xft >= 0.2, utf8-string extensions: ForeignFunctionInterface ... the extension ForeignFunctionInterface in the conditional branch is superflous, as it is specified in any case, so the printer can simplify it to: ... library extensions: ForeignFunctionInterface if flag(use_xft) build-depends: X11-xft >= 0.2, utf8-string ... However the parse result for the two cabal files will differ. Now I gave up here, and added a variable simplifiedPrinting which disables the printer smartness for now. However, I hope someone can make the parser smarter in this respect. 6. If free text starts with a line with a dot, the dot must be in a new line. 7. Version tags have to be printed, which was not the case before (why?). 8. VersionRangeParens needs to be printed. 9. Compiler options have to be put in a canonical order after parsing, which is easy as CompilerFlavors do derive Ord. Kind regards Jürgen Nicklisch-Franken PS. I have added a remark about the new test suite syntax below. ------------------- Appendix1: Test code main = do allCabalFiles <- ... res <- mapM test allCabalFiles if and res then putStrLn "all test succeeded" else putStrLn $ "tests failed: " ++ show (length (filter (== False) res)) ++ " of: " ++ show (length res) test :: FilePath -> IO Bool test cabalFilePath = catch (do gpd <- readPackageDescription silent cabalFilePath writeGenericPackageDescription tempPath gpd gpd2 <- readPackageDescription silent tempPath if gpd == gpd2 then do putStr "." return True else do putStrLn $ "failed for " ++ cabalFilePath return False) (\e -> do putStrLn $ "runtime error " ++ show e ++ " for " ++ cabalFilePath return False) ------------------ Appendix2: lines and unlines revised: -- | 'unlines' is an inverse operation to 'lines'. -- It joins lines, after appending a terminating newline to each. unlines' :: [String] -> String unlines' [] = [] unlines' [x] = x unlines' (x:xs) = x ++ ('\n' : unlines' xs) -- | 'lines' breaks a string up into a list of strings at newline -- characters. The resulting strings do not contain newlines. lines' :: String -> [String] lines' [] = [""] lines' s = let (l, s') = break (== '\n') s in l : case s' of [] -> [] (_:s'') -> lines' s'' ---------------- Appendix 3: I find the test suite syntax problematic, for an exe I have to remeber the combination: test-suite foo type: exitcode-stdio-1.0 main-is: main.hs , and for a module: test-suite bar type: library-1.0 test-module: Bar So its the combination of exitcode-stdio- and main-is or library- and test-module which does the trick. Wouldn't it be easier to write something like: test-suite foo test-version: 1.0 main-is: main.hs , and for a module: test-suite bar test-version: 1.0 test-module: Bar

2 2

[Hackage] #704: sort out design for foreign code in Haskell libraries
by Hackage 09 Nov '10

09 Nov '10

#704: sort out design for foreign code in Haskell libraries ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Currently we often happily add little bits of C glue code into Haskell packages. This is perfectly reasonably but we also want to be able to do things like linking multiple versions of a Haskell package into a single application. That does not work if the C symbols are visible outside of the package (see #701). It seems reasonable to require that C code in a Haskell package respects the properties that we want for Haskell packages. However we must also allow for libraries that are foreign code and not Haskell libraries at all. For example, the zlib binding package ships a complete copy of the zlib C code for platforms that do not have it natively. Unlike bits of FFI glue code, it is unreasonable to expect to change the zlib code to conform to Haskell library requirements. Perhaps what we need is to explicitly identify foreign libraries and hold them to different (lower) standards compared to Haskell libraries. One idea would be to draw together the features proposed in these tickets: * #276 : support for convenience libraries * #148 : producing foreign libraires The idea with convenience libraries is that a package can have multiple libraries in it, even though at most one can be the library that has exposed modules. Other libraries could be used by executables or the main library in that package. The main purpose is sharing but it could also be a way to separate the requirements of haskell code and foreign code. Producing foreign libraries is about making libraries (usually but not necessarily containing Haskell code) that export a foreign C API and are not intended to be used by other Haskell code. Combining these two features would allow for the zlib example to work ok. We would declare a foreign library with the zlib C code and make the main Haskell binding library depend on it. Note that packages that depend on the binding package would not directly link to the C library (this is significant for shared libs). The key constraint for foreign libraries is that we cannot link more than one version into a single application (because the symbols would clash), where as we may assume that it is perfectly safe to link multiple versions of a Haskell package. Any design must also consider symbol visibility. This is relevant both for shared and static libs. With static libs it is hard to avoid every symbol being globally visible. With shared libs there is greater control over symbol visibility but also the restriction on some systems that each shared lib must resolve all symbol references. This means we must more explicitly identify which libraries import symbols from others. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/704> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #399: More information in the Paths_pkg.hs module, or a new module
by Hackage 31 Oct '10

31 Oct '10

#399: More information in the Paths_pkg.hs module, or a new module ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- Comment(by guest): I have a package, where I like to enable debug output based on a package configuration flag. To this end it would be nice to have the state of this Cabal flag as top-level constant in an automatically generated module like Paths. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/399#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal-branches/cabal-1.10): Fix a documentation reference to ghc 6.14
by Duncan Coutts 27 Oct '10

27 Oct '10

Wed Oct 27 06:43:19 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Fix a documentation reference to ghc 6.14 M ./Language/Haskell/Extension.hs -1 +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-branches/cabal-1.10;a…

1 0

patch applied (cabal-branches/cabal-1.10): Add the newer extensions that GHC knows about
by Duncan Coutts 27 Oct '10

27 Oct '10

Wed Oct 27 06:41:27 PDT 2010 Duncan Coutts <duncan(a)haskell.org> * Add the newer extensions that GHC knows about This is a different version of the patch from Cabal HEAD because the representation of extensions is different. M ./Language/Haskell/Extension.hs +53 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-branches/cabal-1.10;a…

1 0