March 2009 - cabal-devel

[Hackage] #318: Library cannnot be used when registered in-place on OS X
by Hackage 08 Jun '09

08 Jun '09

#318: Library cannnot be used when registered in-place on OS X ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.4.0.1 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: Mac OS | ---------------------------------+------------------------------------------ I built and registered a library --inplace using cabal-install on Mac OS X 10.5.4 using cabal-install 0.5.1 and Cabal 1.4.0.1. I was unable to then use the package afterwards. It failed at link-time with: {{{ Linking Main ... ld: in /... blah .../lib/dist/build/lib-0.1.a, archive has no table of contents collect2: ld returned 1 exit status }}} After talking to Beelsebob and dcoutts on #haskell, I used '''ranlib''' on lib-0.1.a, and it worked. According to dcoutts: "it's because we run ranlib when we install it, but not when we first generate it." -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/318> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 14

[Hackage] #185: Temporary executables leave foo.exe.manifest files behind
by Hackage 02 Jun '09

02 Jun '09

#185: Temporary executables leave foo.exe.manifest files behind ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: HEAD Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.1 Platform: Windows | ----------------------+----------------------------------------------------- When Cabal creates and runs a temporary program, as it appears to do with hsc when running over the base libraries doing haddock, it leaves a manifest behind in dist. On Windows, ghc --make with 6.8.1 produces a foo.exe and a foo.exe.manifest. Cabal deletes the former, but not the latter. Very minor, but should be easy to fix too. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/185> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #533: Cabal file in UTF-8 format can not be handled by Cabal
by Hackage 31 May '09

31 May '09

#533: Cabal file in UTF-8 format can not be handled by Cabal ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.2 Severity: normal | Keywords: UTF-8 Difficulty: unknown | Ghcversion: 6.10.1 Platform: Windows | ----------------------------+----------------------------------------------- According to http://www.haskell.org/ghc/docs/latest/html/Cabal/authors.html , a .cabal file should be a Unicode UTF-8 text file; when I change the file to UTF-8 with notepad, Cabal can not handle it: > runhaskell Setup configure Setup: xyz.cabal:1: unrecognised field or section: "\65279Name: xyz" Changing this file back to ANSI solves the problem. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/533> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

[Hackage] #369: Version range printing is inconsistent
by Hackage 31 May '09

31 May '09

#369: Version range printing is inconsistent ----------------------------+----------------------------------------------- Reporter: nominolo | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: HEAD Severity: minor | Keywords: Difficulty: normal | Ghcversion: 6.9 Platform: | ----------------------------+----------------------------------------------- When configuring a package with the following build-depends: {{{ build-depends: base >= 4 && < 5, ghc-paths >= 0.1 && < 0.2, ghc >= 6.10 && < 6.12, ghc-syb >= 0.1 && < 0.2, directory >= 1.0 && < 1.1 }}} configuring fails with: {{{ Setup: At least the following dependencies are missing: ghc-paths ==0.1.* && ==0.1.*, ghc-syb ==0.1.* }}} Note the superfluous {{{ && ==0.1.*}}} in the first missing dependency. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/369> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #525: The install functions copy N executables N times
by Hackage 31 May '09

31 May '09

#525: The install functions copy N executables N times ----------------------------------+----------------------------------------- Reporter: np | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: HEAD Severity: major | Keywords: Difficulty: very easy (<1 hour) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- The patch: Fri Aug 24 17:27:49 CEST 2007 Duncan Coutts <duncan(a)haskell.org> * Only create includes and bin dirs if necessary For includes, don't list the include dir in the package registration info unless we're actually going to install some include files. So we should create fewer pointless empty directories. See bug #97. in particular this hunk: -GHC.installExe verbosity binPref buildPref pkg_descr +withExe pkg_descr $ \_ -> + GHC.installExe verbosity binPref buildPref pkg_descr introduced a bug in the case of packages with multiple executables (notable h4sh has 42 executables, leading to 1764 calls to cp/strip). The withExe is performed twice, once here and once in Dist.Simple.GHC. I attach a simple patch that fixes this problem by using hasExes insted of withExe. Doing the same with 'withLib' in case of future multiple libraries and renaming 'withExe' to 'withExes' would be nice also use these patches as you wish. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/525> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 6

haddock-2.3.0 literate comments discarded from .lhs input
by Alistair Bayley 27 May '09

27 May '09

I have this test case for Haddock (2.3.0): -------------------------------------------------- | Module : Test.Haddock Copyright : (c) 2009 Alistair Bayley License : BSD-style Maintainer : alistair(a)abayley.org Stability : stable Portability : portable Test case for Haddock. > module Test.Haddock > ( > -- $named_block > Fail(..) > ) > where > data Fail = Fail | Succeed $named_block This is some hadock documentation. -------------------------------------------------- This fails with: [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) Test\Fail.hs:11:26: Can't make a derived instance of `Typeable Fail' (You need -XDeriveDataTypeable to derive an instance for this class) In the data type declaration for `Fail' If I manually unlit, then Haddock is happy: -------------------------------------------------- -- | -- Module : Test.Haddock2 -- Copyright : (c) 2009 Alistair Bayley -- License : BSD-style -- Maintainer : alistair(a)abayley.org -- Stability : stable -- Portability : portable -- -- Test case for Haddock. module Test.Haddock2 ( -- $named_block Fail(..) ) where data Fail = Fail | Succeed -- $named_block -- -- This is some hadock documentation. -------------------------------------------------- so it looks as though it's discarding the literate comments. Is this intended? I was under the impression that because it used the ghc parser, it could now properly handle .lhs input. Ona related note, we have a nice unlitter in cabal that would preserve these comments before invoking haddock. Is this still used with haddock2, or does it now assume haddock2 will do the right thing? Alistair

5 27

[Hackage] #504: executables with a C main function
by Hackage 03 May '09

03 May '09

#504: executables with a C main function ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: easy (<4 hours) | Ghcversion: Platform: | ------------------------------+--------------------------------------------- We would like to be able to do: {{{ executable blah main-is: main.c }}} Either for pure C programs or mixed C/Haskell programs with main in the C code rather than Haskell code. == Workaround == Until this is implemented one can use a main in Haskell that calls out to the C main function. For example: `main.c` {{{ int real_main () { return 42; } }}} `Main.hs` {{{ import System.Exit import Foreign.C main = real_main >>= exitWith . ExitFailure . fromIntegral foreign import ccall "real_main" real_main :: IO CInt }}} `c-main.cabal` {{{ name: c-main version: 0.0 build-type: Simple cabal-version: >= 1.2 extra-source-files: main.h executable c-main main-is: Main.hs c-sources: main.c includes: main.h extensions: ForeignFunctionInterface build-depends: base }}} == Implementation notes == At the moment Cabal's "Simple" build system requires `main-is` to specify a `.hs` or `.lhs` file (though it does allow that to be generated by a pre-processor). If we lift that restriction the first thing to go wrong will be that `ghc --make` does not work with `-no-hs-main`. We will have to do the build and link steps separately (which is probably a good thing anyway). We would use `ghc --make` to compile all Haskell modules to `.o` files and then invoke `ghc` in batch mode passing it all the `.o` files (from Haskell and C modules) and `-package` flags. If we're using a C main then we'd do the link step with `-no-hs-main`. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/504> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #231: "buildable: False" should fail the current configuration
by Hackage 27 Apr '09

27 Apr '09

#231: "buildable: False" should fail the current configuration ----------------------------+----------------------------------------------- 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.2 Platform: | ----------------------------+----------------------------------------------- Currently resolving configurations does not take account of the `buildable` field. It should act rather like `build-depends: non- existant`, though with a different error message. If possible the error message should relate to the guard condition expression (the conjunction if there are several nested guards). At the moment it is not considered at all and we don't notice that the package cannot be built until the build step, rather than the configure step. One problem is that it's not clear if `buildable: False` is always fatal. People sometimes do that for test executables that are not supposed to be installed. So what should the behaviour be? The lib or only exe failing to configure must be an error. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/231> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

[Hackage] #338: use of HTTP needs overhauling
by Hackage 24 Apr '09

24 Apr '09

#338: use of HTTP needs overhauling ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ We're not using HTTP the protocol or HTTP the package effectively * As I understand it, the HTTP lib buffers the entire http download in memory rather than returning it lazily, so we cannot stream it to disk. It's also all done using `String`. * We do not check (and nor does the HTTP lib) for truncated downloads. That is where the `Content-Length` header differs from the actual length. * We do not cache the ETag so we cannot optimise the case of re- downloading an unchanged index. * We make a new tcp connection for each download, rather than doing all downloads within a single browse session. * We are not doing downloads concurrent with package builds. We should probably use a dedicated thread for downloads. It should serialise downloads and use a single browse session. Even without support for streaming the body directly we could at least write files atomically, checking length header. And also cache the ETag. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/338> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

[Hackage] #448: cabal-install needs new http download component
by Hackage 24 Apr '09

24 Apr '09

#448: cabal-install needs new http download component ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.3 Platform: | ----------------------------+----------------------------------------------- The way in which cabal-install currently uses the HTTP library API is quite sub-optimal. It starts a new `Broswer` session for each connection. This means that it cannot take advantage of HTTP pipelining, connection pooling and other goodies. One design would involve making some HTTP download object and making requests through that. The download object would start a thread to make the actual requests. Requests would be serialised, eg using a `Chan`. It probably wants to work by directing URLS be downloaded to local files. On top of this we should build some caching mechanism so that we can check for example if our package index is up to date before downloading the whole thing. It would also be nice to check the length and md5 header to catch short or corrupted downloads. Something like: {{{ downloader :: Settings -> IO Downloader download :: Downloader -> URL -> FilePath -> IO () }}} The `download` function is given the URL and the local file path. If the local file exists it is taken to be the cached file. It should download the URL to a temp file in the target directory and if all successful it should atomically rename it over the target file. Perhaps error handling needs to be more explicit than just using `IOError`s. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/448> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1