January 2008 - cabal-devel

Re: [Hackage] #58: allow darcs repo to be specified in cabal file
by Hackage 21 Jan '08

21 Jan '08

#58: allow darcs repo to be specified in cabal file ----------------------------+----------------------------------------------- Reporter: ijones | Owner: ijones Type: enhancement | Status: new Priority: high | Milestone: Cabal-1.4 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * component: HackageDB website => Cabal library * summary: darcs integration idea: track location of darcs repo, create new repo => allow darcs repo to be specified in cabal file Old description: > add a field to cabal to specify a darcs repo. if there's no such field, > create a darcs repo and make it available. accept patches against it and > forward them to upstream author, or just hang on to them New description: add a field to cabal to specify a darcs repo. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/58#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #147: Replace Extension type with (newtyped?) String
by Hackage 21 Jan '08

21 Jan '08

#147: Replace Extension type with (newtyped?) String ----------------------------+----------------------------------------------- Reporter: guest | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: Cabal library | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * priority: high => normal * milestone: Cabal-1.4 => _|_ Comment: Discussion inconclusive. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/147#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #133: sdist and clean should never be given Maybe LocalBuildInfo
by Hackage 21 Jan '08

21 Jan '08

#133: sdist and clean should never be given Maybe LocalBuildInfo ----------------------------+----------------------------------------------- Reporter: guest | Owner: ijones Type: task | Status: new Priority: high | Milestone: Cabal-1.4 Component: Cabal library | Version: 1.1.6 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.4.2 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * difficulty: hard (< 1 day) => normal Comment: `sdist` needs to find pre-processors. That requires the `ProgramConfiguration` which we get during the configure step. We could use the `defaultProgramConfiguration` but then we will fail if we need any non-standard programs. `clean` does not need the `LocalBuildInfo` at all. The current code uses it but it's not justified. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/133#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #50: create compiler frameworks for new compilers
by Hackage 21 Jan '08

21 Jan '08

#50: create compiler frameworks for new compilers ----------------------------+----------------------------------------------- Reporter: ijones | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: project(> week) Ghcversion: 6.2.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * difficulty: very hard => project(> week) * ghcversion: => 6.2.2 * platform: => Comment: The `Compiler` abstraction should certainly be beefed up. I'm not sure we need to go as far as making a external serialised form. Currently the `Compiler` value is passed around but is used as a bit of dumb data when it should really carry methods for doing interesting things and we should not be switching on the `CompilerFlavour`. The difficulty with doing this is that currently the `Compiler` value is passed around using the `LocalBuildInfo` which implements Show. We should really pass `Compiler` as a parameter but we cannot do that without changing the type signatures of the `UserHooks` which would break all custom `Setup` script again. So we have to synchronise this change with our next planned break of `UserHooks`. Ideally that break should include a plan for an api style that does not involve so many breaks when we want to pass just a bit more info, like using some kind of monad where we can extend the environment without breaking existing code. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/50#comment:1> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #101: Rejig the names of hooks provided by Cabal
by Hackage 21 Jan '08

21 Jan '08

#101: Rejig the names of hooks provided by Cabal -----------------------------+---------------------------------------------- Reporter: igloo(a)earth.li | Owner: ijones Type: enhancement | Status: closed Priority: high | Milestone: Component: Cabal library | Version: 1.1.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.6 | Platform: Linux -----------------------------+---------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: We currently export: * `emptyUserHooks` which is almost useless. * `simpleUserHooks` which really is the default - it's what `defaultMain` uses. * `defaultUserHooks` which is not the default. It is now deprecated. * `autoconfUserHooks` which is what defaultUserHooks used to be but with a sensible name and slightly saner behavior. In principle UserHooks could be an instance of `Monoid`. `mempty` would be `emptyUserHooks` and `mappend` could compose actions using `>>`. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/101#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #26: add Threaded as an extension?
by Hackage 21 Jan '08

21 Jan '08

#26: add Threaded as an extension? ----------------------------+----------------------------------------------- Reporter: ijones | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: _|_ Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: easy Ghcversion: 6.2.1 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * priority: high => normal * milestone: Cabal-1.4 => _|_ Comment: The only problem is that threaded applies to the final program. If a library declares that it needs threaded, does that mean we have to propagate the flag and use it with all programs that use it? Propagating GHC flags is not possible currently - by design. GHC used to have such a feature and it was removed. Or perhaps we say it's an extension that only applies to executables? -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/26#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #32: add -DPACKAGE_FOO_VERSION=1.1 to cpp command line
by Hackage 21 Jan '08

21 Jan '08

#32: add -DPACKAGE_FOO_VERSION=1.1 to cpp command line ----------------------------+----------------------------------------------- Reporter: ijones | Owner: ijones Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.4 Component: Cabal library | Version: Severity: normal | Resolution: Keywords: | Difficulty: easy Ghcversion: 6.2.2 | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * priority: high => normal * platform: => * ghcversion: => 6.2.2 Comment: Does we really want it? We've got this far without needing it. Perhaps people are using something worse, like __GLASGOW_HASKELL__ >= 608 as a proxy for what they really mean which is probably __PACKAGE_BASE_VERSION__ >= 3. Or perhaps they're being good and if we make it too easy and provide all these package versions then people will start doing more naughty cpp stuff. They can already make cpp flags for package versions using configurations: {{{ flag bytestringInBase library if flag(bytestringInBase) build-depends: base >= 2 && < 3 cpp-options: -DBYTESTRING_IN_BASE else build-depends: base < 2 || >= 3 }}} -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/32#comment:2> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #37: check to see whether we should be adding symbols to cpphs more often
by Hackage 21 Jan '08

21 Jan '08

#37: check to see whether we should be adding symbols to cpphs more often ----------------------------+----------------------------------------------- Reporter: ijones | Owner: ijones Type: task | Status: closed Priority: high | Milestone: Component: Cabal library | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: normal Ghcversion: 6.2.1 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => fixed Comment: Nobody has complained about this for a while. I'll assume we're passing enough flags now. It looks like we pass the same flags for cpp or cpphs. If we're still missing some please open a new bug and provide details. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/37#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #165: The ./configure configure hook should complain if ./configure does not exist
by Hackage 21 Jan '08

21 Jan '08

#165: The ./configure configure hook should complain if ./configure does not exist ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal | Version: 1.2.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.4.2 Platform: Linux | ---------------------+------------------------------------------------------ We often have problems with people not running auto(re)conf before Setup configure, and things breaking later on. The hook that runs ./configure should fail if ./configure doesn't exist; it probably shouldn't give any suggestion on how to create it, as people will blindly follow the suggestion and one size probably won't fit all. This essentially depends on the proposals to split up hooks into smaller, composable parts. Ian Lynagh -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/165> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 3

Re: [Hackage] #161: 'sdist' cannot find some modules that 'build' finds ok
by Hackage 21 Jan '08

21 Jan '08

#161: 'sdist' cannot find some modules that 'build' finds ok ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.2.0 Severity: normal | Resolution: Keywords: | Difficulty: easy (<4 hours) Ghcversion: 6.6 | Platform: Linux ----------------------------+----------------------------------------------- Changes (by duncan): * summary: sdist and build uses different source directories => 'sdist' cannot find some modules that 'build' finds ok Old description: > With the following project layout: > > network-bytestring > network-bytestring.cabal > Network > Socket > ByteString.hscpp > tests > ... > ... > > Running configure, build and install works but running sdist results in: > > Setup.lhs: Error: Could not find module: Network.Socket.ByteString with > any suffix: ["gc","chs","hsc","x","y","ly","cpphs","hs","lhs"] > > I added some more debug output with the following result: > > Setup.lhs: Error: Could not find module: Network.Socket.ByteString with > any suffix: ["gc","chs","hsc","x","y","ly","cpphs","hs","lhs"] in any of > these search directories: ["tests"] > > My theory is that builds includes "." among the source directories while > sdist doesn't. > > You can get the repo (with a possibly fixed .cabal file so you need to > look at the attached file to reproduce the error): > > darcs get http://code.haskell.org/network-bytestring New description: With the following project layout: {{{ network-bytestring network-bytestring.cabal Network Socket ByteString.hscpp tests ... ... }}} Running configure, build and install works but running sdist results in: {{{ Setup.lhs: Error: Could not find module: Network.Socket.ByteString with any suffix: ["gc","chs","hsc","x","y","ly","cpphs","hs","lhs"] }}} I added some more debug output with the following result: {{{ Setup.lhs: Error: Could not find module: Network.Socket.ByteString with any suffix: ["gc","chs","hsc","x","y","ly","cpphs","hs","lhs"] in any of these search directories: ["tests"] }}} My theory is that builds includes "." among the source directories while sdist doesn't. You can get the repo (with a possibly fixed .cabal file so you need to look at the attached file to reproduce the error): darcs get http://code.haskell.org/network-bytestring -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/161#comment:3> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0