June 2009 - cabal-devel

working on a fix for ticket #212
by Laszlo Nagy 06 Jul '09

06 Jul '09

Hi All, Trying to create unit test suite.. work in progress. Comments are more than welcome! http://sites.google.com/site/rizsotto/patches/cabal-ticket-212-v1.darcs-send As an easy start, I wrote unit tests with QuickCheck on the following files: Distribution/License.hs Distribution/Package.hs Distribution/Compiler.hs Distribution/System.hs Distribution/ModuleName.hs Distribution/PackageDescription.hs I wrote simple properties like this, for all data type > prop_parse x = x == parse $ display x I did merged the existing QuickCheck test cases into one file. I found it easier to reuse the generator functions for different types. My findings: - The System.Platform did not passed parse tests. The reason: both System.OS and System.Arch allowed the dash character in the name. But System.Platform text representation was concatenate the two strings separated by a dash. So I just simple removed the dash from them. Solved! ;) - VersionRange does not passes parse tests, iff more than two ranges is present. As far as I could see, the parse method is wired to handle only two ranges. Not corrected, because found no good solution. Need help on this! - Package.Dependency also not passes parse tests. (It is depend on VersionRange success.) - Compat.ReadR gather property is obsolete and does not compile. Can't figure it out how could I rewrite it. Need help! - PackageDescription does not passes simple parse test. I guess the problem is with the test itself! ;) I used showPackageDescription method to generate string representation of this type and parse it back. I could not judge it is an expected behaviour or a bug. Need some explanation. My problem is mainly how to run these tests? As unit tests they are pure, does not manipulate any files on disks, does not open socket or anything. (Michael Feathers use the unit test word as strict as this.) So, I expected to run them by anyone, who could compile the sources. #1 'cabal test' could be the best way to exercise them. But the user hook is so complicated for a simple 'compile and run'. Found others ignoring the arguments and call System.Cmd, execute _the compiler_. The compiler name is wired and dependencies also not visible enough, not to mention the extension handling. Basically compile by hand is against cabal! :) (Pro: the best way to invoke; Con: very hard to do) #2 Create testing flag in the cabal file, which enable an executable to be build. (Xmonad guys doing this way.) It compiles easy, developer need not worry about different compilers. Running the test can be done by hand (or darcs) or the test user hook can execute it. If the main product is a library, then it does not link against that, since the library is not installed. Instead developers specify the source dir and it recompiles the tested sources. (Pro: easy to do; Cons: does not test against library) #3 Create another cabal file. Roughly speaking it is same as #2. In my opinion it is suite best for functional tests. (Pro: easy to do; Cons: testing target must be installed first) #4 Use the QuickCheck script. Based naming convention this script runs through the sources, 'grep' the properties, and exec an interpreter to run them. (Pro: easy; Cons: interpreter name is wired in the script) #5 As a proposed long term solution: I might add a new parameter to the 'executable' region describe the target is a unit test. Compile (and run) it only on 'cabal test' invocation. (Con: It does not exists and might be hard to implement :)) Thanks for any help! Regards, Laszlo

3 8

[Hackage] #563: absoluteInstallDirs changed signature, breaks darcs Setup
by Hackage 05 Jul '09

05 Jul '09

#563: absoluteInstallDirs changed signature, breaks darcs Setup ----------------------------+----------------------------------------------- Reporter: mornfall | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- In Cabal 1.7.2 (i.e. recent HEAD), I get: Setup.lhs:168:43: Couldn't match expected type `Distribution.Package.PackageId' against inferred type `PackageDescription' In the first argument of `absoluteInstallDirs', namely `pkg' In the first argument of `mandir', namely `(absoluteInstallDirs pkg lbi copy)' In the first argument of `(</>)', namely `mandir (absoluteInstallDirs pkg lbi copy)' (This works as expected with Cabal 1.6.) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/563> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #330: Take non-haddock documentation in account
by Hackage 01 Jul '09

01 Jul '09

#330: Take non-haddock documentation in account ----------------------------+----------------------------------------------- Reporter: fons | 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: | ----------------------------+----------------------------------------------- The generation and installation of Non-Haddock documentation (README and INSTALL files, LaTeX and Docbook tutorials/guides, Haskell examples using the package in question) is not currently taken in account by Cabal. Making Cabal understand how to generate documentation for all those formats would probably be too ambitious, but it could be eased (e.g. letting the user provide Makefiles instead of creating custom hooks). More importantly, the installation of documentation would be much easier with a new package property such as "doc-files" ("data-files" nor "extra- source-files" are semantically suitable). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/330> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

Dependencies from .cabal files
by Erik de Castro Lopo 01 Jul '09

01 Jul '09

Hi all, I hope this is the right list to ask this. Please direct me to the right place if not. Anyway, I'm using functionality in the Distribution.* namespace to parse .cabal files retrieved from Hackage. The problem is that after using flattenPackageDescription, the buildDepends of the PackageDescription structure seems to be a flat list which seems to lose information that was in the original .cabal file. For instance, the cabal file for hoogle, contains: build-depends: parsec, filepath, safe, uniplate, mtl, time if flag(splitBase) build-depends: base >= 3, directory, process, containers, array, bytestring else build-depends: base < 3 while the buildDepends list looks like this: Dependency (PackageName "base") (EarlierVersion (Version {versionBranch = [3], versionTags = []})), Dependency (PackageName "bytestring") AnyVersion, Dependency (PackageName "array") AnyVersion, Dependency (PackageName "containers") AnyVersion, Dependency (PackageName "process") AnyVersion, Dependency (PackageName "directory") AnyVersion, Dependency (PackageName "base") (UnionVersionRanges (ThisVersion (Version {versionBranch = [3], versionTags = []})) (LaterVersion (Version {versionBranch = [3], versionTags = []}))), Dependency (PackageName "time") AnyVersion, Dependency (PackageName "mtl") AnyVersion, Dependency (PackageName "uniplate") AnyVersion, Dependency (PackageName "safe") AnyVersion, Dependency (PackageName "filepath") AnyVersion, Dependency (PackageName "parsec") AnyVersion Should the conversion from .cabal file to Dependency list be lossy? I look forward to enlightenment. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

2 3

[Hackage] #325: SHGetFolderPath requiered to configure cabal 1.4
by Hackage 30 Jun '09

30 Jun '09

#325: SHGetFolderPath requiered to configure cabal 1.4 ----------------------------+----------------------------------------------- Reporter: guest | 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: | ----------------------------+----------------------------------------------- i try to install cabal with ghc 6.8.3 on XP. i get the error message GHCi could not find the following symbols SHGetFolderPath i saw some old bugs mentioning this problem - what is a current fix? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/325> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

patch applied (cabal): Help Cabal find gcc/ld on Windows
by Simon Marlow 29 Jun '09

29 Jun '09

Fri Jun 26 07:02:50 PDT 2009 Simon Marlow <marlowsd(a)gmail.com> * Help Cabal find gcc/ld on Windows Ignore-this: bad21fe3047bc6e23165160c88dd53d9 the layout changed in the new GHC build system M ./Distribution/Simple/GHC.hs -8 +18 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090626140250-12142-118d9aa8…

1 0

Re: [Hackage] #93: Incorrect permissions on library install
by Hackage 27 Jun '09

27 Jun '09

#93: Incorrect permissions on library install ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: reopened Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.1.4 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.10.1 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by GregoryWeber): * status: closed => reopened * ghcversion: 6.4.2 => 6.10.1 * resolution: fixed => Comment: Replying to [comment:7 duncan]: > Fixed in cabal head and the 1.6 branch. > > The behavior now when installing is that we ignore the permissions the files had in the build tree and the user's umask. We explicitly set permissions for all files we install. > That seems to be working well for most files, but those listed in the data-files field of the Cabal package are still installed with permission rw for the owner (root), zero permission for group and others. {{{ [root@squirrel cal3d-examples-0.1]# uname -a Linux squirrel.localdomain 2.6.27.25-170.2.72.fc10.i686 #1 SMP Sun Jun 21 19:03:24 EDT 2009 i686 i686 i386 GNU/Linux [root@squirrel cal3d-examples-0.1]# ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 [root@squirrel cal3d-examples-0.1]# ghc-pkg list Cabal /usr/lib/ghc-6.10.1/./package.conf: Cabal-1.6.0.1 [root@squirrel cal3d-examples-0.1]# runghc Setup install Installing executable(s) in /opt/bin [root@squirrel cal3d-examples-0.1]# cd /opt/share/cal3d-examples-0.1/ [root@squirrel cal3d-examples-0.1]# ls -l total 4 drwxr-xr-x 2 root root 4096 2009-06-27 17:13 data [root@squirrel cal3d-examples-0.1]# ls -l data total 696 -rw------- 1 root root 6400 2009-06-27 17:13 cally_calf_left.cmf -rw------- 1 root root 6464 2009-06-27 17:13 cally_calf_right.cmf -rw------- 1 root root 16968 2009-06-27 17:13 cally_chest.cmf -rw------- 1 root root 210 2009-06-27 17:13 cally_chest.xrf -rw------- 1 root root 3216 2009-06-27 17:13 cally.csf [snip] }}} I can work around this by doing {{{ chmod -Rf g+rX,o+rX . }}} in the source directory where I am developing the package, __before__ building the source tarballs for release. Of course, likewise the installer can do so after unpacking the tarballs, or even after the files are installed. Seems like this might be a big nuisance for projects using darcs with multiple developers, since darcs does not preserve file permissions. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/93#comment:8> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal): clean up createTempDirectory, using System.Posix or System.Directory
by Simon Marlow 26 Jun '09

26 Jun '09

Thu Jun 25 03:56:48 PDT 2009 Simon Marlow <marlowsd(a)gmail.com> * clean up createTempDirectory, using System.Posix or System.Directory Ignore-this: 732aac57116c308198a8aaa2f67ec475 rather than low-level System.Posix.Internals operations which are about to go away. M ./Cabal.cabal +3 M ./Distribution/Compat/TempFile.hs -10 +22 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20090625105648-12142-11f8b023…

1 0

[Hackage] #458: inconsistent use of CPPFLAGS, LDFLAGS etc with build-type Configure
by Hackage 26 Jun '09

26 Jun '09

#458: inconsistent use of CPPFLAGS, LDFLAGS etc with build-type Configure ----------------------------+----------------------------------------------- Reporter: duncan | 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: | ----------------------------+----------------------------------------------- We have a mismatch between the cabal Setup scripts which ignore `LDFLAGS` etc and provide `--extra-lib-dirs` instead, and some `./configure` scripts which grab the `CCFLAGS` etc and bung them into a `.buildinfo` file. This is bad because it means --extra-lib-dirs does not work for those packages and it also means that those packages consult the CCFLAGS etc and others do not. It's quite an inconsistent user interface. We should try to make it more consistent. One approach would be for cabal to consider the CCFLAGS etc, to combine them with the flags passed on the command line and those specified in the .cabal file. (We have code to analyse CC/LD/CPP flags and to split them up into the standard BuildInfo fields.) Then for configure scripts we could pass the whole lot. The danger of course is that the configure scripts duplicate it all and put it into a .buildinfo file. Another tempting option is to call configure with a clean environment so that it cannot pick up these vars. Unfortunately that might break some existing packages. We should be careful with the use of these env vars though, because while it's fine to change the user interface to cabal-install, the interface to the Setup.hs is a machine interface and the more we require of it, the more has to be implemented by every different build system. A case in point is the curl package. It has a .buildinfo file like: {{{ cc-options: @CPPFLAGS@ ld-options: @LDFLAGS@ }}} The `./configure` script checks: {{{ AC_TRY_CPP([#include <curl/curl.h>],,[no_curl=yes]) }}} Which uses the `CPPFLAGS`. So it's adding an extra package-specific user interface by consulting these environment variables. At the same time the configure script ignores the `--extra-lib-dirs=` and `--extra-include-dirs=` Setup.hs command line flags. This means that users doing what is advertised will find the package does not work. Indeed changing to `build-type: Simple` and deleting the configure script makes it work perfectly. So this mismatch is clearly harmful. See also #262 which should make these checks redundant. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/458> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 4

Re: [Hackage] #89: Sharing of object files between executable builds?
by Hackage 25 Jun '09

25 Jun '09

#89: Sharing of object files between executable builds? ---------------------------------+------------------------------------------ Reporter: bjorn(a)bringert.net | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ---------------------------------+------------------------------------------ Changes (by nomeata): * cc: nomeata (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/89#comment:14> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0