- cabal-devel - Haskell.org

Re: [Hackage] #382: 'cabal ghci' mode
by Hackage 05 Aug '10

05 Aug '10

#382: 'cabal ghci' mode ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: major | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Changes (by kolmodin): * cc: kolmodin@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/382#comment:12> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #656: Cabal-1.8-style dependencies stop Haddock from working
by Hackage 04 Aug '10

04 Aug '10

#656: Cabal-1.8-style dependencies stop Haddock from working ------------------------------+--------------------------------------------- Reporter: Ivan Miljenovic | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: Linux | ------------------------------+--------------------------------------------- Comment(by Dybber): The patch doesn't seem to fix the issue for me, but I can confirm that it has something to do with the executable generation. When I remove the Executable-sections from my .cabal I no longer get the "Can't find transitive deps"-error. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/656#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

preprocessSources
by Phyx 30 Jul '10

30 Jul '10

I'm trying to use the Cabal api to preprocess a .cabal file and have it run the preprocessors. But preprocessSources takes a PackageDescription (which I get from a GenericPackageDescription) so this does not contain any information on the Executables or Libraries in the cabal file. So nothing gets executed. What is the correct way to use it? For reference, my code is preprocessPackage :: Context -> String -> IO () preprocessPackage env file = do info <- maybeGetPersistBuildConfig configName outdated <- case info of Just i -> safeCheckPersistBuildConfig "dist" file Nothing -> return True pkg_info <- case outdated of False -> return $ fromJust info True -> do new_info <- configurePackage env writePersistBuildConfig configName new_info return new_info withContext env (\cfg -> preprocessSources (packageDescription cfg) pkg_info False deafening knownSuffixHandlers)

2 1

[Hackage] #721: Unknown subsections are silently ignored
by Hackage 29 Jul '10

29 Jul '10

#721: Unknown subsections are silently ignored ----------------------------+----------------------------------------------- Reporter: ezyang | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.4 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- Sections not on the top-level (like those used in conditionals) appear to be ignored silently if they are not recognized. {{{ Name: cabal-elseif Version: 0.1 License: BSD3 License-file: LICENSE Category: Bug Build-type: Simple Cabal-version: >=1.2 Library if os(linux) { Ghc-options: -O2 } elseif os(windows) { Ghc-options: -O } }}} Expected behavior: Cabal warns that elseif is not a supported section name Actual behavior: Cabal silently accepts this and ignores the elseif section. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/721> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #720: Executables fail on windows if the executable name has a dot in it
by Hackage 28 Jul '10

28 Jul '10

#720: Executables fail on windows if the executable name has a dot in it ----------------------------+----------------------------------------------- Reporter: j3h | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- If an executable name has a dot in it, it is not generated with an .exe extension on Windows. It works fine under Linux. See the attached example to reproduce. {{{ $ cabal --version cabal-install version 0.8.2 using version 1.8.0.6 of the Cabal library $ cabal install Resolving dependencies... Configuring bad-exe-0.1... Preprocessing executables for bad-exe-0.1... Building bad-exe-0.1... [1 of 1] Compiling Main ( Main.hs, dist\build\bad.name\bad .name-tmp\Main.o ) Main.hs:1:0: Warning: Module `Prelude' is deprecated: You are using the old package `base' version 3.x. Future GHC versions will not support base version 3.x. You should update your code to use the new base version 4.x. Linking dist\build\bad.name\bad.name ... Installing executable(s) in C:\Users\hudson\AppData\Roaming\cabal\bin cabal.exe: dist\build\bad.name\bad.name.exe: does not exist cabal.exe: Error: some packages failed to install: bad-exe-0.1 failed during the final install step. The exception was: ExitFailure 1 }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/720> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

patch applied (cabal): Add two local type signatures
by Ian Lynagh 28 Jul '10

28 Jul '10

Wed Jul 28 09:35:39 PDT 2010 simonpj@microsoft/com * Add two local type signatures I'm adding these type signatures to satisfy the "do not generalise local let/where" rule that GHC is taking on. The signatures are clearly correct, but I was surprised at the polymorphism needed. For example parseOptVersion :: ReadP r Version parseOptVersion = parseQuoted ver <++ ver where ver :: ReadP r Version ver = parse <++ return noVersion noVersion = Version{ versionBranch=[], versionTags=[] } Note that 'ver' really is called at two different types! That in turn is because of the type of (<++) (<++) :: ReadP a a -> ReadP r a -> ReadP r a (+++) :: ReadP r a -> ReadP r a -> ReadP r a Note the "a a" in the first arg, which is very unusual. For example, compare the type of (+++). Changing it to match the type of (+++) makes ReadP fail to compile, though, so I assume it's right as it stands. But surely this deserves a comment?! M ./Distribution/ParseUtils.hs -6 +9 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal;a=darcs_commitdiff;h=…

1 0

[Hackage] #718: Behaviour of postCopy and postInstall hook is confusing
by Hackage 28 Jul '10

28 Jul '10

#718: Behaviour of postCopy and postInstall hook is confusing ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.8.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- While working on the Bluetile cabal package ( http://hackage.haskell.org/package/bluetile ) I used Cabal's hook system to install executables to the libexec directory. It took me a while to figure out that the postCopy hook is _the only hook_ to run when you invoke 'cabal copy' and the postInstall hook is _the only hook_ to run when you invoke 'cabal install'. This is both confusing and unfortunate. Since the Cabal documentation elsewhere states that 'cabal install' is just "register + copy" one would assume that upon 'cabal install' the postCopy hook runs as well. Now I had to write two hooks, both for postCopy and for postInstall, to make it work for users that run 'cabal install' as well as cases where 'cabal copy' is used (for example by distributions, while preparing their packages). This can probably not be fixed without breaking a bunch of Cabal packages, so maybe some kind of warning or big note in the documentation would help in the meantime. Best regards! Jan -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/718> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #717: Expose libexec option in simple build system
by Hackage 24 Jul '10

24 Jul '10

#717: Expose libexec option in simple build system ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal specification | Version: 1.8.0.2 Severity: normal | Keywords: libexec helper executable Difficulty: unknown | Ghcversion: Platform: | ----------------------------------+----------------------------------------- For my Bluetile Cabal package ( http://hackage.haskell.org/package/bluetile ) I would like to install some of the executables into the libexec target directory. Cabal already supports a libexec directory, there is just no easy way to get an executable copied there. So I had to write my own custom hooks. To simplify things, I would like to suggest the option of marking an executable to be installed in the libexec directory. I propose a simple flag 'Is-Helper-Executable: True/False' which could be specified as part of an 'Executable' section. Setting this to True should result in Cabal installing the executable to the libexec directory. Quick example of why one wants to use the libexec directory in the first place: Bluetile has a number of such helper applications. While having Bluetile packaged for Debian, it turned out that Debian requires a man page for every binary under /usr/bin. So I would have had to write man pages for every helper application or - which seemed like the proper way to do it - have them installed under /usr/lib/bluetile/ (libexec directory). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/717> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #538: --constraint= is not respected for base
by Hackage 23 Jul '10

23 Jul '10

#538: --constraint= is not respected for base ---------------------------------+------------------------------------------ Reporter: Saizan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.6.0.2 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Changes (by duncan): * component: Cabal library => cabal-install tool Comment: The problem is in the cabal-install constraint solver. We handle packages like base specially (base 3 depends on base 4). We do it by whenever we select one we also select the other. However clearly at the end when we pick one we're ignoring some constraint. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/538#comment:1> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #288: the package indexes are very slow
by Hackage 20 Jul '10

20 Jul '10

#288: the package indexes are very slow ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Comment(by duncan): Replying to [comment:5 AntoineLatter]: > Experience report: > > Taking the tar-index from hackage-server wasn't too hard. It doesn't scale to hackage-sized tarballs, though - it is only able to store the offsets for about half of the .cabal files in 00-index.tar. It should be straightforward to extend the size of the types used to cope with bigger tarballs. The only cost will be a bigger index. The reason for the limitations in the hackage code is simply to save space by keeping the indexes very compact. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/288#comment:6> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

3 3