- cabal-devel - Haskell.org

patch applied (cabal): Swap haddock inplace/install dirs that were accidentally the wrong way round
by Duncan Coutts 24 Aug '07

24 Aug '07

Thu Aug 23 08:42:58 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Swap haddock inplace/install dirs that were accidentally the wrong way round M ./Distribution/Simple/Register.hs -2 +2

1 0

patch applied (cabal): Fix register --gen-script
by Duncan Coutts 24 Aug '07

24 Aug '07

Thu Aug 23 08:42:18 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * Fix register --gen-script It's still useless on Windows. M ./Distribution/Simple/Register.hs -11 +8

1 0

Why is --gen-script creating failing scripts?
by Marc Weber 23 Aug '07

23 Aug '07

I've been using the recent cabal from ghc-6.7.20070814 register.sh [...] haddock-html: /pr/store/5wivrfz8pmc7hpwqgxgz44i4ihf1ka09-ghc67_filepath-1.0/nix-support/share/filepath-1.0/doc/html/filepath' | /pr/store/khvbwb3whj1c15pg7jrh7w4v2vndr8i7-ghc-6.7.20070814/bin/ghc-pkg update dist/installed-pkg-config - marc@localhost /tmp/nix-10368-0/filepath-1.0 $ ghc-pkg list /pr/store/khvbwb3whj1c15pg7jrh7w4v2vndr8i7-ghc-6.7.20070814/lib/ghc-6.7.20070814/package.conf: Cabal-1.1.7, [...] Please use either echo and add - or pass the pkg-conf dist/installed-pkg-config .. or did I mess something up? If you like I can start debugging the issue and read the source.. But propably you know what has been changed ? Marc

2 1

D.Program depends on D.Simple.Utils
by Clemens Fruhwirth 23 Aug '07

23 Aug '07

Hi, I was about to extend Dist.Simple.Utils with a method called mkSharedLibName, which depends on Compiler information, hence Dist.Simple.Utils was about to import Dist.Compiler. I ran into this dependency loop: Module imports form a cycle for modules: Cabal-1.1.7:Distribution.Compiler imports: <..> Distribution.Program <...> Cabal-1.1.7:Distribution.Program imports: <..> Distribution.Simple.Utils <..> Cabal-1.1.7:Distribution.Simple.Utils imports: <..> Distribution.Compiler <..> make: *** [.depend] Error 1 After a short discussion on #ghc, Esa Ilari Vuokko explained that Dist.* is not supposed to depend on Dist.Simple.*, so it seems reasonable to break the dependency cycle at "Program -> Simple.Utils". Program imports 'die' and two program execution helpers 'rawSystemExit' and 'rawSystemStdout' from Simple.Utils. Two dependencies on 'die' could be removed easily, hunk ./Distribution/Program.hs 192 - Nothing -> die ("Cannot find " ++ prog ++ " on the path") $ + Nothing -> return EmptyLocation hunk ./Distribution/Program.hs 213 - _ -> die ("cannot determine version of " ++ name ++ " :\n" ++ show str) + _ -> return prog { programVersion = Nothing } but the other two uses seems rather ok to me (is it ok to _|_ when an API is used in an illegal way?), namely: rawSystemProgram _ prog@(Program { programLocation = EmptyLocation }) _ = die ("Error: Could not find location for program: " ++ programName prog) Esa suggested a wider refactoring, namely to remove rawSystemExit and rawSystemStdout from Program.hs. Esa, you could explain the details? Would it be ok to move 'die' and the rawSystem helpers into the Dist.* hierarchy if this takes longer to resolve? -- Fruhwirth Clemens - http://clemens.endorphin.org

2 3

patch applied (cabal): The prologue.txt is not needed for anything
by Duncan Coutts 23 Aug '07

23 Aug '07

Wed Aug 22 14:41:22 PDT 2007 Duncan Coutts <duncan(a)haskell.org> * The prologue.txt is not needed for anything The text from the description is now used for haddock R ./prologue.txt

1 0

Re: [Hackage] #38: craft workaround for gentoo which allows them to generate package.conf file but not register
by Hackage 23 Aug '07

23 Aug '07

#38: craft workaround for gentoo which allows them to generate package.conf file but not register --------------------------+------------------------------------------------- Reporter: ijones | Owner: ijones Type: enhancement | Status: reopened Priority: high | Milestone: Component: Cabal | Version: Severity: normal | Resolution: Keywords: | Ghcversion: 6.2.1 Difficulty: normal | Platform: Linux --------------------------+------------------------------------------------- Changes (by ross(a)soi.city.ac.uk) * resolution: fixed => * status: closed => reopened Comment: The interface change is not documented in the User's Guide. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/38> Hackage <http://example.com/> My example project

1 0

[Hackage] #149: Support for building and linking resource files in Windows
by Hackage 23 Aug '07

23 Aug '07

#149: Support for building and linking resource files in Windows --------------------------+------------------------------------------------- Reporter: eivuokko | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Keywords: Ghcversion: 6.4.2 | Difficulty: normal Platform: Linux | --------------------------+------------------------------------------------- Cabal should allow specifying resource scripts and files and link them to at least executable (.exe and .dll). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/149> Hackage <http://example.com/> My example project

1 1

Re: [Hackage] #7: add --ghc-args and such to configure
by Hackage 23 Aug '07

23 Aug '07

#7: add --ghc-args and such to configure ----------------------------------+----------------------------------------- Reporter: ijones | Owner: ijones Type: enhancement | Status: reopened Priority: high | Milestone: Cabal-1.2 Component: Cabal | Version: 1.1.3 Severity: normal | Resolution: Keywords: | Ghcversion: 6.2.1 Difficulty: very easy (<1 hour) | Platform: Linux ----------------------------------+----------------------------------------- Changes (by ross(a)soi.city.ac.uk) * resolution: fixed => * status: closed => reopened Comment: Done in the code, but not documented in the User's Guide. A design issue: there is a difference in naming and semantics from --configure-option (and ghc-option elsewhere). The latter takes only one option, so multiple options must each be wrapped individually. That can be a bit more cumbersome, but it avoids issues with embedded spaces. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/7> Hackage <http://example.com/> My example project

1 0

[Hackage] #148: Cabal should be able to produce DLLs in Windows
by Hackage 23 Aug '07

23 Aug '07

#148: Cabal should be able to produce DLLs in Windows -----------------------+---------------------------------------------------- Reporter: eivuokko | Owner: ijones Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.1.6 Severity: normal | Keywords: Ghcversion: 6.4.2 | Difficulty: normal Platform: Windows | -----------------------+---------------------------------------------------- GHC supports linking final executable into a DLL instead of normal executable. Cabal should support this use, and also support specifying DEF file for exports and building an import library. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/148> Hackage <http://example.com/> My example project

1 1

Re: [Hackage] #55: should cabal-upload be a thin wrapper on cabal-install?
by Hackage 23 Aug '07

23 Aug '07

#55: should cabal-upload be a thin wrapper on cabal-install? ---------------------------+------------------------------------------------ Reporter: ijones | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.4 Component: cabal-upload | Version: Severity: normal | Resolution: Keywords: | Ghcversion: 6.2.1 Difficulty: normal | Platform: Linux ---------------------------+------------------------------------------------ Comment (by ross(a)soi.city.ac.uk) I don't see the connection. cabal-upload is currently a small program that wraps a package in a request to the upload CGI script, while cabal-install fetches the files it needs via HTTP. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/55> Hackage <http://example.com/> My example project

1 0