July 2010 - cabal-devel

[Hackage] #666: configure should warn about using base 3
by Hackage 24 Sep '10

24 Sep '10

#666: configure should warn about using base 3 ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.3 Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- http://haskell.org/pipermail/haskell-cafe/2010-April/076823.html For backwards compatibility we make cabal-install prefer base 3 if there is no upper bound on the version of base. This is necessary however it is also confusing. People writing new packages should be getting base 4. We want to encourage people to use base 4, as version 3 is deprecated. We should make `cabal configure` warn if base 3 is selected since this is deprecated. The message should indicate the appropriate solution, ie to put an upper bound on the version of base. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/666> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

[Hackage] #708: extension list
by Hackage 21 Aug '10

21 Aug '10

#708: extension list ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- I was going to add the new `DatatypeContexts` extension to Cabal's extension list, but the datatype confused me. It seems to list the extensions relative to Haskell98 (i.e. `NoFoo` if Foo is H98, `Foo` otherwise), but this seems odd now that we also have a Haskell2010 standard. And does it allow extensions to be toggled on or off, regardless of which way they are listed in the datatype? Also, the haddock comments refer the GHC manual sections, but don't say what version of GHC's manual the numbers refer to. I think it would be better to drop the numbers, rather than having to manually keep them up- to-date - especially as someone might use a Cabal release with a different GHC version. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/708> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #710: Track license-file
by Hackage 10 Aug '10

10 Aug '10

#710: Track license-file ----------------------------+----------------------------------------------- Reporter: elliottt | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: Platform: | ----------------------------+----------------------------------------------- ghc-pkg has supported (since 6.4) a license-file field in the package database. It would be useful to make this information available inside of Cabal, as guesses have to be made as to the location of the license file, currently. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/710> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

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 28 Jul '10

28 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 23 Jul '10

23 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